From: "Stone Wang" <pwstone@gmail.com>
To: "Dave Hansen" <haveblue@us.ibm.com>
Cc: akpm@osdl.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH][5/8] proc: export mlocked pages info through "/proc/meminfo: Wired"
Date: Wed, 22 Mar 2006 01:02:44 -0500 [thread overview]
Message-ID: <bc56f2f0603212202l5cb41f5h@mail.gmail.com> (raw)
In-Reply-To: <1142977393.10906.204.camel@localhost.localdomain>
2006/3/21, Dave Hansen <haveblue@us.ibm.com>:
> On Mon, 2006-03-20 at 08:37 -0500, Stone Wang wrote:
> > --- linux-2.6.15.orig/include/linux/mm.h 2006-01-02 22:21:10.000000000 -0500
> > +++ linux-2.6.15/include/linux/mm.h 2006-03-07 01:49:12.000000000 -0500
> > @@ -218,6 +221,10 @@
> > unsigned long flags; /* Atomic flags, some possibly
> > * updated asynchronously */
> > atomic_t _count; /* Usage count, see below. */
> > + unsigned short wired_count; /* Count of wirings of the page.
> > + * If not zero,the page would be SetPageWired,
> > + * and put on Wired list of the zone.
> > + */
> > atomic_t _mapcount; /* Count of ptes mapped in mms,
> > * to show when page is mapped
> > * & limit reverse map searches.
>
> We're usually pretty picky about adding stuff to 'struct page'. It
> _just_ fits inside a cacheline on most 32-bit architectures.
>
> Can this wired_count not be derived at runtime? It seems like it would
> be possible to run through all VMAs mapping the page, and determining
> how many of them are VM_LOCKED. Would that be too slow?
It can be derived, but perhaps would made code not that clear.
I will try accroding to your comments, and i think there could be
fast scanning of the vma list for this purpose.
> Also, does it matter how many times it is locked, or just that
> _somebody_ has it locked?
For now, it just matters somebody has it locked.
When munlock a page, it matters somebody else has it locked.
>
> -- Dave
>
>
WARNING: multiple messages have this Message-ID (diff)
From: "Stone Wang" <pwstone@gmail.com>
To: Dave Hansen <haveblue@us.ibm.com>
Cc: akpm@osdl.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH][5/8] proc: export mlocked pages info through "/proc/meminfo: Wired"
Date: Wed, 22 Mar 2006 01:02:44 -0500 [thread overview]
Message-ID: <bc56f2f0603212202l5cb41f5h@mail.gmail.com> (raw)
In-Reply-To: <1142977393.10906.204.camel@localhost.localdomain>
2006/3/21, Dave Hansen <haveblue@us.ibm.com>:
> On Mon, 2006-03-20 at 08:37 -0500, Stone Wang wrote:
> > --- linux-2.6.15.orig/include/linux/mm.h 2006-01-02 22:21:10.000000000 -0500
> > +++ linux-2.6.15/include/linux/mm.h 2006-03-07 01:49:12.000000000 -0500
> > @@ -218,6 +221,10 @@
> > unsigned long flags; /* Atomic flags, some possibly
> > * updated asynchronously */
> > atomic_t _count; /* Usage count, see below. */
> > + unsigned short wired_count; /* Count of wirings of the page.
> > + * If not zero,the page would be SetPageWired,
> > + * and put on Wired list of the zone.
> > + */
> > atomic_t _mapcount; /* Count of ptes mapped in mms,
> > * to show when page is mapped
> > * & limit reverse map searches.
>
> We're usually pretty picky about adding stuff to 'struct page'. It
> _just_ fits inside a cacheline on most 32-bit architectures.
>
> Can this wired_count not be derived at runtime? It seems like it would
> be possible to run through all VMAs mapping the page, and determining
> how many of them are VM_LOCKED. Would that be too slow?
It can be derived, but perhaps would made code not that clear.
I will try accroding to your comments, and i think there could be
fast scanning of the vma list for this purpose.
> Also, does it matter how many times it is locked, or just that
> _somebody_ has it locked?
For now, it just matters somebody has it locked.
When munlock a page, it matters somebody else has it locked.
>
> -- Dave
>
>
--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2006-03-22 6:02 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-20 13:37 [PATCH][5/8] proc: export mlocked pages info through "/proc/meminfo: Wired" Stone Wang
2006-03-20 13:37 ` Stone Wang
2006-03-21 12:21 ` Nick Piggin
2006-03-21 12:21 ` Nick Piggin
2006-03-21 15:33 ` Stone Wang
2006-03-21 15:33 ` Stone Wang
2006-03-21 19:43 ` Arjan van de Ven
2006-03-21 19:43 ` Arjan van de Ven
2006-03-22 0:22 ` Nick Piggin
2006-03-22 0:22 ` Nick Piggin
2006-03-22 5:37 ` Stone Wang
2006-03-22 5:37 ` Stone Wang
2006-03-22 7:23 ` Nick Piggin
2006-03-22 7:23 ` Nick Piggin
2006-03-22 9:04 ` Arjan van de Ven
2006-03-22 9:04 ` Arjan van de Ven
2006-03-24 16:34 ` Rik van Riel
2006-03-24 16:34 ` Rik van Riel
2006-03-24 16:38 ` Nick Piggin
2006-03-24 16:38 ` Nick Piggin
2006-03-24 18:19 ` Rik van Riel
2006-03-24 18:19 ` Rik van Riel
2006-03-24 18:25 ` Nick Piggin
2006-03-24 18:25 ` Nick Piggin
2006-03-21 21:43 ` Dave Hansen
2006-03-21 21:43 ` Dave Hansen
2006-03-22 6:02 ` Stone Wang [this message]
2006-03-22 6:02 ` Stone Wang
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=bc56f2f0603212202l5cb41f5h@mail.gmail.com \
--to=pwstone@gmail.com \
--cc=akpm@osdl.org \
--cc=haveblue@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.