Re: [PATCH] sched/kthread: Complain loudly when others violate our flags

[Tejun Heo <htejun@gmail.com>]

Hello,

On Fri, Sep 30, 2011 at 12:08:45AM -0400, Steven Rostedt wrote:
> On Thu, 2011-09-29 at 20:55 -0700, Tejun Heo wrote:
> > On Tue, Sep 27, 2011 at 05:17:34PM -0400, Steven Rostedt wrote:
> > > For convenience and optimization, we are going to use the task's flag
> > > PF_THREAD_BOUND as a way to know if a task is bound to a CPU or not. As
> > > that is what the flag means.
> > 
> > And I'm not sure this is a very good idea.  Until now, PF_THREAD_BOUND
> > meant "this task is explicitly bound to the current affinity (whatever
> > it is) and thus it shouldn't be manipulated by third party".
> 
> That's exactly what we want it to mean. Not manipulated by workqueue or
> anyone else.

Umm... those are wq workers and wq is third party?  I'm sorry that you
wasted your time but let's please drop the bickering over the
interpretation of the flag.

> We don't plan on setting this flag if a task just happens
> to have only one CPU in its affinity. We only set this flag if the task
> is bounded to a CPU for good. When we see this flag set, we can therefor
> assume that it will not migrate!

Up to now, it did NOT mean that.  It just blocked out affinity
manipulation by third party and cpuset attach.  From what you write, I
think the added assumptions are...

* The affinity should be confined to single CPU.

* Once set, the flag can't be cleared and affinity can't be changed by
  anyone.

Am I right?

> > suggested change makes the flag much less orthogonal and useful.  How
> > much of convenience and optimization are we talking about?
> 
> Enough to not have to manually pin the task to the cpu at every lock.

As I wrote before we can test PF_WQ_WORKER too where appropriate
(probably just set_cpus_allowed_ptr) and avoid using PF_THREAD_BOUND
for wq workers.  We can also add a new flag but w/ wq being the only
user, that probably is an overkill.

Thank you.

-- 
tejun