From: Daniel Phillips <phillips@bonn-fries.net>
To: Marcelo Tosatti <marcelo@conectiva.com.br>,
lkml <linux-kernel@vger.kernel.org>
Cc: Andrew Morton <akpm@zip.com.au>, Zach Brown <zab@osdlab.org>,
linux-mm@kvack.org
Subject: Re: vmstats patch against 2.4.8pre7 and new userlevel hack
Date: Fri, 10 Aug 2001 22:33:31 +0200 [thread overview]
Message-ID: <01081022333100.00293@starship> (raw)
In-Reply-To: <Pine.LNX.4.21.0108090326470.14424-100000@freak.distro.conectiva>
On Thursday 09 August 2001 08:45, Marcelo Tosatti wrote:
> I've updated the vmstats patch to use Andrew Morton's statcount facilities
> (which is in initial development state). I've also removed/added some
> statistics due to VM changes.
I applied it and added some of my own statistics. Very nice, much nicer than
the traditional compile-reboot-measure-the-time cycle.
For one thing, it means you can watch the system in operation under a test
load and see what it's really doing. Chances are, you know right then
whether it's running well or not and don't have to wait till the end of a
long test run.
Problem: none of the statistics show up in proc until the first time the
kernel hits them. The /proc/stats entry isn't even there until the kernel
hits the first statistic. This isn't user-friendly.
I can see that this patch is going to break a lot between kernel updates,
because it touches precisely the places we work on all the time - that's why
the stats are there, right? I'd suggest breaking it into two patchs, one
with all the support and a few basic statistics in stable places, and another
that adds in the rest of your current favorite vm stats. It would also be
nice if the stats were broken up into sets that can be catted out of proc
onto the screen, in other words, sets of 23 or less. This would mean that
that something like watch cat /proc/stats/vm is already an effective
interface.
I already learned a lot more about the what's actually happening inside the
vm using this. One thing that surprised me is how few locked pages there
actually are on the inactive_dirty list. I suppose I'd need a heavy mmap
load to see more activity there. Maybe a heavy write load would show up more
there, but for now it looks like there are so few of those locked pages it
won't interfere with scanning performance at all.
> On the userlevel side, I got zab's cpustat nice tool and transformed it
> into an ugly hack which allows me to easily add/remove statistic
> counters.
I didn't get that to work. It seemed to be looking at the wrong /proc file.
I didn't look into it further.
--
Daniel
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/
next prev parent reply other threads:[~2001-08-10 20:33 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-08-09 6:45 Marcelo Tosatti
2001-08-10 20:33 ` Daniel Phillips [this message]
2001-08-11 16:57 ` Marcelo Tosatti
2001-08-11 22:33 ` Andrew Morton
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=01081022333100.00293@starship \
--to=phillips@bonn-fries.net \
--cc=akpm@zip.com.au \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=marcelo@conectiva.com.br \
--cc=zab@osdlab.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* 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