[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20071022211709.7be79fea.pj@sgi.com>
Date: Mon, 22 Oct 2007 21:17:09 -0700
From: Paul Jackson <pj@....com>
To: Steven Rostedt <rostedt@...dmis.org>,
Paul Menage <menage@...gle.com>
Cc: linux-kernel@...r.kernel.org, linux-rt-users@...r.kernel.org,
torvalds@...ux-foundation.org, akpm@...ux-foundation.org,
mingo@...e.hu, dmitry.adamushko@...il.com, ghaskins@...ell.com,
a.p.zijlstra@...llo.nl
Subject: Re: [PATCH -v2 4/7] RT overloaded runqueues accounting
Steven wrote:
> +void cpuset_rt_set_overload(struct task_struct *tsk, int cpu)
> +{
> + cpu_set(cpu, task_cs(tsk)->rt_overload);
> +}
Question for Steven:
What locks are held when cpuset_rt_set_overload() is called?
Questions for Paul Menage:
Does 'tsk' need to be locked for the above task_cs() call?
Background concern -- one of the things that I like to think has
allowed cpusets to be useful to others is the careful documentation
of its locking requirements. I hope that the cgroup infrastructure,
and the portions of the cpuset code, such as this task_cs() call,
that were adapted to work with cgroups, have their locking needs
documented as well. I suspect that there is still some presence of
stale cpuset locking comments, and perhaps an absence of complete
comments on new cgroup locking needs. My recollection is that this
is already on your todo list -- I'm just being annoying here ;).
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <pj@....com> 1.925.600.0401
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists