Re: [PATCH 0/13] maps: pagemap, kpagemap, and related cleanups
- From: Nick Piggin <nickpiggin@xxxxxxxxxxxx>
- Date: Fri, 13 Apr 2007 11:14:20 +1000
Andrew Morton wrote:
On Fri, 13 Apr 2007 10:15:24 +1000 Nick Piggin <nickpiggin@xxxxxxxxxxxx> wrote:
+ for (; i < 2 * chunk / KPMSIZE; i += 2, pfn++) {
+ ppage = pfn_to_page(pfn);
+ if (!ppage) {
+ page[i] = 0;
+ page[i + 1] = 0;
+ } else {
+ page[i] = ppage->flags;
+ page[i + 1] = atomic_read(&ppage->_count);
+ }
+ }
Not a good idea to expose raw flags in this manner - it changes at the drop
of a hat. We'd need to also expose the kernel's PG_foo-to-bitnumber
mapping to make this viable.
I don't think it is viable because that makes the flags part of the
userspace ABI.
It *will* be viable. If the application wants to know if a page is dirty,
it looks up "PG_dirty" in /proc/pg_foo-to-bitnumber and uses PG_dirty's
numerical offset when inspecting fields in /proc/kpagemap. If correctly
designed, such a monitoring application will be able to report upon page
flags which we haven't even thought up yet.
Ooh, you wanted a _runtime_ mapping of flags, yeah then I guess that works.
Still seems like a basically hit and miss affair to just use flags. What if
you want to know the process mapping a page? With systemtap or something you
could walk the rmap structures. What if you want to look at pages along the
LRU list rather than per-pfn? What about connecting pages to inodes?
I thought this type of deep poking was the whole reason the probles thingies
were merged. I'm saddened that they're no good for this. I thought it would
be an ideal usage :(
I wonder what they are needed for.
Poking deeply into the kernel to provide information about kernel state.
There are real-world needs for this, and the people who develop tools to
process this information will have decent kernel understanding and will
know that the file's contents may alter across kernel versions. It sure
beats poking around in /dev/kmem.
I doubt if there's a sensible way in which we can prettify this interface
without losing information. But we should aim to make it as robust as
possible agaisnt future kenrel changes, of course.
And we should satisfy ourselves that all the required information has been
made available. The fact that it will satisfy the Oracle requirement is
encouraging.
Yeah it is close, they need page_mapcount I think. But I was going to say
that satisfying an Oracle requirement is a good reason _not_ to merge it ;)
(I joke!)
--
SUSE Labs, Novell Inc.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
- Follow-Ups:
- Re: [PATCH 0/13] maps: pagemap, kpagemap, and related cleanups
- From: Andrew Morton
- Re: [PATCH 0/13] maps: pagemap, kpagemap, and related cleanups
- References:
- [PATCH 0/13] maps: pagemap, kpagemap, and related cleanups
- From: Matt Mackall
- Re: [PATCH 0/13] maps: pagemap, kpagemap, and related cleanups
- From: William Lee Irwin III
- Re: [PATCH 0/13] maps: pagemap, kpagemap, and related cleanups
- From: Andrew Morton
- Re: [PATCH 0/13] maps: pagemap, kpagemap, and related cleanups
- From: Nick Piggin
- Re: [PATCH 0/13] maps: pagemap, kpagemap, and related cleanups
- From: Andrew Morton
- [PATCH 0/13] maps: pagemap, kpagemap, and related cleanups
- Prev by Date: Re: [patch] convert aio event reap to use atomic-op instead of spin_lock
- Next by Date: Re: [PATCH 0/13] maps: pagemap, kpagemap, and related cleanups
- Previous by thread: Re: [PATCH 0/13] maps: pagemap, kpagemap, and related cleanups
- Next by thread: Re: [PATCH 0/13] maps: pagemap, kpagemap, and related cleanups
- Index(es):
Relevant Pages
|
