lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 20 Feb 2007 14:48:17 -0800
From:	Max Krasnyansky <maxk@...lcomm.com>
To:	Christoph Lameter <clameter@....com>
CC:	linux-kernel@...r.kernel.org
Subject: SLAB cache reaper on isolated cpus

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 ?

Max




-
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ