From: Andy Whitcroft <apw@shadowen.org>
To: Andrew Morton <akpm@osdl.org>
Cc: Badari Pulavarty <pbadari@us.ibm.com>,
linux-mm@kvack.org, linux-fsdevel@vger.kernel.org
Subject: Re: page flags ?
Date: Thu, 19 May 2005 11:51:37 +0100 [thread overview]
Message-ID: <428C6FB9.4060602@shadowen.org> (raw)
In-Reply-To: <20050518162302.13a13356.akpm@osdl.org>
Andrew Morton wrote:
> Anything's possible ;)
>
> How many bits are spare now? ZONETABLE_PGSHIFT hurts my brain.
The short answer is that on 32 bit architectures there are 24 bits
allocated to general page flags, page-flags.h indicates that 21 are
currently assigned so assuming it is accurate there are currently 3 bits
free.
Perhaps this my cue to chip in and provide some commentry on the
zonetable patches.
Before the zonetable patches the flags were essentially split into two
sections, the top 8 bits for the NODEZONE 'pointer' and the remaining 24
bits for page flags. The NODEZONE bits were further subdivided into
NODE and ZONE. For i386 for instance 2 bits were allocated to ZONE and
6 bits for NODE. There was no flexibility in layout.
32 24 0
| NODE | ZONE | ... | FLAGS |
The zonetable patches came out of the need to add a new field into this
area; the SECTION field for the SPARSEMEM work. This meant that we
wanted to be able to specify both the size and packing order for these
fields. This would allow us to specify unused fields as 0 width to
reclaim precious bits. It would also allow us to optimise order such
that the key performance critical mapping from page to struct zone
pointer was efficient to extract (a single shift). This key is commonly
NODE,ZONE but may be SECTION,ZONE when short of space, the two fields in
use need to be contigious and preferably at the left.
The zonetable patches work by allowing us to simply define the width of
each field we are using and the order of those fields. Field widths are
defined by the *_WIDTH definitions, these are either the architecture
specific default width *_SHIFT or 0 where the field is not required (for
instance if not used by the current memory model). The field order is
defined by the relationships between the *_PGOFF definitions, packing
them from the left of the field. Access to these fields is via the
*_PGSHIFT and *_MASK defines. Care is taken to ensure that they are
valid for a zero with field. The ZONETABLE_PGSHIFT and _MASK define the
combined key field used to locate the struct zone for this page.
Overall the allocation to the NODEZONE area is defined to be the highest
order FLAGS_RESERVED bits of the flags word (8 on 32 bit architectures,
and 32 on 64 bit). The overall allocation to this field is unchanged.
-apw
--
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:"aart@kvack.org"> aart@kvack.org </a>
next prev parent reply other threads:[~2005-05-19 10:51 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-05-18 21:13 Badari Pulavarty
2005-05-18 21:56 ` Andrew Morton
2005-05-18 22:42 ` Badari Pulavarty
2005-05-18 23:23 ` Andrew Morton
2005-05-19 0:09 ` Badari Pulavarty
2005-05-19 0:26 ` Chandra Seetharaman
2005-05-19 1:36 ` Dave Hansen
2005-05-19 10:51 ` Andy Whitcroft [this message]
2005-05-19 11:11 ` Andrew Morton
2005-05-19 14:37 ` Nikita Danilov
2005-05-19 18:29 ` Badari Pulavarty
2005-05-19 22:53 ` Andrew Morton
2005-05-19 23:34 ` Badari Pulavarty
2005-05-20 0:03 ` Martin J. Bligh
2005-05-19 23:55 ` Badari Pulavarty
2005-05-20 0:20 ` Martin J. Bligh
2005-05-18 23:57 ` Bryan Henderson
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=428C6FB9.4060602@shadowen.org \
--to=apw@shadowen.org \
--cc=akpm@osdl.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=pbadari@us.ibm.com \
/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