LKML Archive on
help / color / mirror / Atom feed
From: Max Krasnyansky <>
To: Christoph Lameter <>
Subject: SLAB cache reaper on isolated cpus
Date: Tue, 20 Feb 2007 14:48:17 -0800	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

Christoph Lameter wrote:
> On Tue, 20 Feb 2007, Max Krasnyansky wrote:
>> Ok. Sounds like disabling cache_reaper is a better option for now. Like you said
>> it's unlikely that slabs will grow much if that cpu is not heavily used by the kernel.
> Running for prolonged times without cache_reaper is no good.
> What we are talking about here is to disable the cache_reaper during cpu 
> shutdown. The slab cpu shutdown will clean the per cpu caches anyways so 
> we really do not need the slab_reaper running during cpu shutdown.

Ok. Let me restart the thread so that we're not confusing two issues :).

I'm not talking about CPU shutdown or CPU hotplug in general. My proposal seemed related
to the CPU shutdown issue that you guys were discussing, but it turns out it's not.

Suppose I need to isolate a CPU. We already support at the scheduler and irq levels (irq affinity).
But I want to go a bit further and avoid doing kernel work on isolated cpus as much as possible.
For example I would not want to schedule work queues and stuff on them.
Currently there are just a few users of the schedule_delayed_work_on(). cpufreq (don't care for
isolation purposes), oprofile (same here) and slab.
For the slab it'd be nice to run the reaper on some other CPU. But you're saying that locking
depends on CPU pinning. Is there any other option besides disabling cache reap ? Is there a way
for example to constraint the slabs on CPU X to not exceed N megs ?


  reply	other threads:[~2007-02-20 22:48 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-29  1:13 slab: start_cpu_timer/cache_reap CONFIG_HOTPLUG_CPU problems Oleg Nesterov
2007-01-29 16:54 ` Christoph Lameter
2007-01-29 17:19   ` Oleg Nesterov
2007-01-29 17:27     ` Christoph Lameter
2007-01-29 18:27       ` Oleg Nesterov
2007-01-29 19:09         ` Christoph Lameter
2007-01-29 19:29           ` Oleg Nesterov
2007-01-29 19:25         ` Christoph Lameter
2007-01-29 19:49           ` Oleg Nesterov
2007-01-29 20:29             ` Christoph Lameter
2007-01-29 21:05               ` Oleg Nesterov
2007-01-29 21:48                 ` Christoph Lameter
2007-01-29 22:14                   ` Oleg Nesterov
2007-02-20 18:39         ` Max Krasnyansky
2007-02-20 18:45           ` Christoph Lameter
2007-02-20 20:05             ` Oleg Nesterov
2007-02-20 21:22               ` Max Krasnyansky
2007-02-20 21:35                 ` Christoph Lameter
2007-02-20 22:01                   ` Max Krasnyansky
2007-02-20 22:14                     ` Christoph Lameter
2007-02-20 22:48                       ` Max Krasnyansky [this message]
2007-02-20 23:19                         ` SLAB cache reaper on isolated cpus Christoph Lameter
2007-02-21  3:41                           ` Max Krasnyansky
2007-02-20 21:05             ` slab: start_cpu_timer/cache_reap CONFIG_HOTPLUG_CPU problems Max Krasnyansky
2007-02-20 21:34               ` Christoph Lameter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).