On Mon, Nov 30, 2020 at 09:31:47AM +0000, Christoph Lameter wrote: > 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? Could be. Or disallow certain operations such as CPU hotplug, ring buffer resize, etc. > > 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. Yes, thanks.
