On Fri, 27 Nov 2020, Marcelo Tosatti wrote: > Decided to switch to prctl interface, and then it starts > to become similar to "task mode isolation" patchset API. Right I think that was a good approach. > In addition to quiescing pending activities on the CPU, it would > also be useful to assign a per-task attribute (which is then assigned > to a per-CPU attribute), indicating whether that CPU is running > an isolated task or not. Sounds good but what would this do? Give a warning like the isolation patchset? > This per-CPU attribute can be used to, for example, return -EBUSY > from ring_buffer_resize() (or any other IPI generating activity > which can return an error to userspace). Yes good. > So rather than: > > prctl(PR_QUIESCE_CPU) (current interface, similar to > initial message on the thread but with prctl rather than > sysfs) > > To be called before real time loop, one would have: > > prctl(PR_SET_TASK_ISOLATION, ISOLATION_ENABLE) [1] > real time loop > prctl(PR_SET_TASK_ISOLATION, ISOLATION_DISABLE) > > (with the attribute also being cleared on task exit). > > The general description would be: > > "Set task isolated mode for a given task, returning an error > if the task is not pinned to a single CPU. > > In this mode, the kernel will avoid interruptions to isolated > CPUs when possible." > > Any objections against such an interface ? Maybe do both like in the isolation patchset? Often code can tolerate a few interruptions (in some code branches regular syscalls may be needed) but one wants the thread to be as quiet as possible.
