Re: slab: start_cpu_timer/cache_reap CONFIG_HOTPLUG_CPU problems

[Max Krasnyansky <maxk@qualcomm.com>]

Oleg Nesterov wrote:
> On 02/20, Christoph Lameter wrote:
> > On Tue, 20 Feb 2007, Max Krasnyansky wrote:
> >
> > > > > Well seems that we have a set of unresolved issues with workqueues and cpu
> > > > > hotplug.
> > > How about storing 'cpu' explicitly in the work queue instead of relying on the
> > > smp_processor_id() and friends ? That way there is no ambiguity when
> > > threads/timers get
> > > moved around.
> > The slab functionality is designed to work on the processor with the 
> > queue. These tricks will only cause more trouble in the future. The 
> > cache_reaper needs to be either disabled or run on the right processor. It 
> > should never run on the wrong processor.
>
> I personally agree. Besides, cache_reaper is not alone. Note the comment
> in debug_smp_processor_id() about cpu-bound processes. The slab does correct
> thing right now, stops the timer on CPU_DEAD. Other problems imho should be
> solved by fixing cpu-hotplug. Gautham and Srivatsa are working on that.

I guess I kind of hijacked the thread. The second part of my first email was
dropped. Basically I was saying that I'm working on CPU isolation extensions.
Where an isolated CPU is not supposed to do much kernel work. In which case
you'd want to run slab cache reaper on some other CPU on behalf of the isolated
one. Hence the proposal to explicitly pass cpu_id to the reaper. I guess now
that you guys fixed the hotplug case it does not help in that scenario.

Max
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/