linux-kernel - Re: vmstat: use our own timer events

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]

Message-ID: <Pine.LNX.4.64.0704292138480.1737@schroedinger.engr.sgi.com>
Date:	Sun, 29 Apr 2007 21:44:03 -0700 (PDT)
From:	Christoph Lameter <clameter@....com>
To:	Andrew Morton <akpm@...ux-foundation.org>
cc:	linux-kernel@...r.kernel.org,
	Arjan van de Ven <arjan@...ux.intel.com>
Subject: Re: vmstat: use our own timer events

On Sun, 29 Apr 2007, Andrew Morton wrote:

> > on each node at the second and then each of the other processor on a
> > node on a subsequent tick. That may be useful to keep a large amount
> > of the second free of timer activity. Maybe the timer folks will have
> > some feedback on this one?
> 
> The one-per-second timer interrupt will upset the people who are really
> aggressive about power consumption (eg, OLPC).  Perhaps there isn't (yet)
> an intersection between those people and SMP.

Well the cache_reaper of SLAB hits hard todays anyways. This will help
if they switch to slub because the counter consolidation is much lighter 
weight.

> However a knob to set the frequency would be nice, if it's not too
> expensive to implement.  Presumably anyone who cares enough will come along
> and add one, but then they have to wait for a long period for that change
> to propagate out to their users, which is a bit sad for something which we
> already knew about.

Ok will do.
 
> Having each CPU touch every zone looks a bit expensive - I'd have thought
> that it would be showing up a little on your monster NUMA machines?

Vmstat updates only touch cachelines that are node local. Data from
remote zones may be updated but pcps of those remote zones are for
this processor and have been placed local to the processor accessing them.

Thus no problem for monster NUMA.

> Oh dear.  Some of these new notifier types are added by a patch which is a
> few hundred patches later than slub.  I can park this patch after that one,
> but that introduces a risk that later slub patches will also get
> disconnected.

I am fine with delaying this. I just wanted the timer guys to have a 
chance to shape this a bit. Not sure what they want. What they did to the 
cache_reaper in 2.6.20/21 is bad.

-
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/