On Thu, Nov 4, 2010 at 6:57 AM, Robert P. J. Day <rpjday@xxxxxxxxxxxxxx> wrote:
> 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.
AFAIK, they 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.
Yes. PG_Compound is still there for backward compatibility.
PG_Compound flag was introduced before the PG_Head & the PG_Tail flag.
Compound Page only tells you that it is a part of a higher order page.
But it doesn't tell you if the particular instance is a head page or
tail page. Generally, we would like to know whether a given page is a
head page page or a tail page because a head page needs special
processing. If we come across an individual tail page of a compound
page, it is most probably in error because it is a part of higher
order page. Other option is to treat it like any other small page. We
cannot know this information (that, it is a head or a tail page) if
two seperate page flags for the head & the tail pages are not used.
Both the head & the tail pages are part of a single unit. So, the
PageCompound(..) function now becomes :
PageCompund(struct page *page) {
return PageHead(page) || PageHead(page);
}
So, basically you should not use PageCompound(..) or PG_Compound
anymore. Handling of higher order pages in the kernel is more
efficient if we have two separate page flags (PG_Head & PG_Tail)
instead of just one (PG_Compound). It reveals us more information &
hence we can handle the higher order pages better. So, the bottomline
is : "Using two page flags for higher order pages is more efficient".
Venkatram Tummala
>
>> 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
