Re: removing mm->rss and mm->anon_rss from kernel?

From: Martin J. Bligh <>
Date: 2004-11-09 03:14:34
--Christoph Lameter <> wrote (on Monday, November 08, 2004 08:04:05 -0800):

> On Sun, 7 Nov 2004, Martin J. Bligh wrote:
>> Doing ps or top is not unusual at all, and the sysadmins should be able
>> to monitor their system in a reasonable way without crippling it, or even
>> effecting it significantly.
> Hmm.. What would you think about a pointer to a stats structure in mm,
> which would only be allocated if stats are requested by /proc actions? The
> struct would contain a timestamp which would insure that the stats are
> only generated in certain intervals and not over and over again. This
> would also make it possible to force a regeneration of the numbers.
> Maybe lots of other statistical values in mm_struct could then also be
> removed?

So basically it's the same thing except you're caching it. If you want 
stale old data, you can cache it in userspace, rather than hack the
kernel ... personally, I think it's utterly pointless - if the user didn't
want the data, then they wouldn't be requesting it.
>> Ummm 10K cpus? I hope that's a typo for processes, or this discussion is
>> getting rather silly ....
> Nope. The future of computing seems to be very high numbers of cpus.
> NASAs Columbia has 10k cpus and the new BlueGen solution from IBM is
> already at 8k.

I see where the figure comes from, but each node comes with it's own memory,
so it's rather pointless to talk about total over the number of nodes. It'd
make as much sense to tot up the total number of processors on all Linux
installs in the world, and use that figure ;-)

What exactly was the problem? Far too many atomic ops flying around on a
512 CPU machine? Can't you just say that if the mm count is only 1, then 
don't bother with atomic? That'd fix all non-multi-threaded workloads,
I'd think.


To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
the body of a message to
More majordomo info at
Received on Mon Nov 8 11:15:44 2004

This archive was generated by hypermail 2.1.8 : 2005-08-02 09:20:32 EST