On Wed, 3 Nov 2010, Venkatram Tummala wrote:
> Compound Page is a page which has greater size than the system-wide
> page size. Compound pages are mainly used by HugeTLB code. In some
> architectures, multiple page sizes are supported. For Ex. x86_64
> also supports 2 MB also in addition to 4KB pages which is the
> default setting when you compile a kernel. So, on a kernel
> configured with 4KB page size, if you do a alloc_pages (..) of say
> order 9, you will have a total 2MB worth of pages. As the
> architecture supports 2MB page sizes, basically one TLB entry is
> enough for 2MB worth of memory instead of 512 entries, if HugeTLB is
> used.
ok, that makes sense. and i'm assuming that 2MB worth of pages
doesn't need to live on a 2MB boundary.
also, as i read it, compound pages is the normal situation, given
this test in <linux/page-flags.h>:
#ifdef CONFIG_PAGEFLAGS_EXTENDED
PG_head, /* A head page */
PG_tail, /* A tail page */
#else
PG_compound, /* A compound page */
#endif
so if there *aren't* extended page flags, you get the standard
support of compound pages which (i'm assuming as i haven't gone back
to check yet) has all the pages in a compound page share flags.
but if you have extended page flags, then each of those pages can
have their own page flag setting, does that make sense? i suspect it
will all be clear when i go back and look again.
> So, the way it works on a 4KB page size kernel is you get the
> following : HTTTTTT.......T (total of 512) . 'H' indicating a head
> page & 'T' indicating a tail page. For a tail page, the 'first_page'
> field of 'struct page' will point to the head page. This 2 MB worh
> of memory will be treated as a single page conceptually. What that
> means, the refcounts on these individual 512 4K pages are equal.
> They are equal to the refcount of the head page. Everytime, you get
> a ref on a page, the refcount on the head page is modified. If you
> have support for extended page flags, these flags can be used to
> indicate whether a given page is a head page or a tail page. Thats
> all there's to it.
ok, i'll puzzle this out in a bit, thanks.
rday
--
========================================================================
Robert P. J. Day Waterloo, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ
