[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.64.0702201334361.17198@schroedinger.engr.sgi.com>
Date: Tue, 20 Feb 2007 13:35:42 -0800 (PST)
From: Christoph Lameter <clameter@....com>
To: Max Krasnyansky <maxk@...lcomm.com>
cc: Oleg Nesterov <oleg@...sign.ru>, Ingo Molnar <mingo@...e.hu>,
Srivatsa Vaddagiri <vatsa@...ibm.com>,
"Pallipadi, Venkatesh" <venkatesh.pallipadi@...el.com>,
Gautham shenoy <ego@...ibm.com>, Andrew Morton <akpm@...l.org>,
linux-kernel@...r.kernel.org
Subject: Re: slab: start_cpu_timer/cache_reap CONFIG_HOTPLUG_CPU problems
On Tue, 20 Feb 2007, Max Krasnyansky wrote:
> 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.
A cpu must have a per cpu cache in order to do slab allocations. The
locking in the slab allocator depends on it.
If the isolated cpus have no need for slab allocations then you will also
not need to run the slab_reaper().
-
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