Back in October 2007, this thread to which I am now (Jan 2008)
responding had a discussion of realtime versus normal load balancing
and how to setup sched domains for this, perhaps using cpusets.
Thanks to Peter Zijlstra, this discussion has started up again on lkml,
in the new thread:
http://
Steven wrote:
> Ingo Molnar and Peter Zijlstra pointed out to me that this global cpumask
> would kill performance on >64 CPU boxes due to cacheline bouncing. To
> solve this issue, I placed the RT overload mask into the cpusets.
This feels rather like sched domains to me (which I can't claim
to u
--
On Mon, 22 Oct 2007, Paul Menage wrote:
> On 10/22/07, Paul Jackson <[EMAIL PROTECTED]> wrote:
> > Steven wrote:
> > > +void cpuset_rt_set_overload(struct task_struct *tsk, int cpu)
> > > +{
> > > + cpu_set(cpu, task_cs(tsk)->rt_overload);
> > > +}
> >
> > Question for Steven:
> >
> > Wh
Paul M wrote:
> Cgroups doesn't change the locking rules for accessing a cpuset from a
> task - you have to have one of:
Good - could you comment task_cs() with this explanation?
The rules are derived from the cpuset rules, as you explain,
and as I suspected, but now task_cs() is the most popular
On 10/22/07, Paul Jackson <[EMAIL PROTECTED]> wrote:
> 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?
>
> Qu
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 t
6 matches
Mail list logo
