Messages in this thread | | | Date | Fri, 11 Jun 2021 10:10:08 -0700 | From | "Paul E. McKenney" <> | Subject | Re: Question about a8ea6fc9b089 ("sched: Stop PF_NO_SETAFFINITY from being inherited by various init system threads") |
| |
On Fri, Jun 11, 2021 at 03:19:29PM +0100, Valentin Schneider wrote: > On 11/06/21 06:52, Paul E. McKenney wrote: > > On Fri, Jun 11, 2021 at 11:12:29AM +0100, Valentin Schneider wrote: > >> > >> The way I see 570a752b7a9b is that, if a task is pinned to a single CPU but > >> doesn't have PF_NO_SETAFFINITY, then userspace can unpin it. This means it > >> ought to have entered check_preemption_disabled() with preemption disabled > >> - right now it may be pinned, but that can change at any minute, and > >> whatever code it is running needs to cope with that. > > > > Thank you for catching me up on this topic! > > > >> Could you share some details on which tasks you are hitting this with? > > > > Let's start with ref_scale_reader() in kernel/rcu/refscale.c. This > > is for fine-grained in-kernel benchmarking, so it really wants kthreads > > running this function to be pinned. > > > > I took a look at kthread_bind(), but it is not intended to be called by > > the kthread itself. Looking elsewhere in the kernel, it looks like I > > just do this right after invoking set_cpus_allowed_ptr(): > > > > current->flags != PF_NO_SETAFFINITY; > > > > Or am I missing a better way to handle this? > > Looking at ref_scale_reader(), ISTM the initial configuration (affinity, > niceness) should be done by its parent thread, not by itself. i.e.: > > p = kthread_create(ref_scale_reader); > kthread_bind(p, cpu); // Does the pinning + sets PF_NO_SETAFFINITY > set_user_nice(p, MAX_NICE); > wake_up_process(p); > > (kthread_create_on_cpu() is also an option) > > >From what I can see, torture_create_kthread() immediately wakes the > newly-created kthread, we'd need a version that calls kthread_create() > instead of kthread_run() for the above. Would that be an issue?
It sounds much simpler for me to just continue using raw_smp_processor_id() instead of trying to switch back to smp_processor_id(). ;-)
Thanx, Paul
| |