On Fri, 2006-09-08 at 09:36 +0100, Mel Gorman wrote:
> On Thu, 7 Sep 2006, Andrew Morton wrote:
>
> > On Thu, 7 Sep 2006 20:03:42 +0100 (IST)
> > Mel Gorman <[email protected]> wrote:
> >
> >> When a page is allocated, the page-flags
> >> are updated with a value indicating it's type of reclaimability so that it
> >> is placed on the correct list on free.
> >
> > We're getting awful tight on page-flags.
> >
>
> Yeah, I know :(
>
> > Would it be possible to avoid adding the flag? Say, have a per-zone bitmap
> > of size (zone->present_pages/(1<<MAX_ORDER)) bits, then do a lookup in
> > there to work out whether a particular page is within a MAX_ORDER clump of
> > easy-reclaimable pages?
> >
>
> An early version of the patches created such a bitmap and it was heavily
> resisted for two reasons. It put more pressure on the cache and it needed
> to be resized during hot-add and hot-remove. It was the latter issue
> people had more problems with. However, I can reimplement it if people
> want to take a look. As I see it currently, there are five choices that
> could be taken to avoid using an additional pageflag
>
> 1. Re-use existing page flags. This is what I currently do in a later
> patch for the software suspend flags
> pros: Straight-forward implementation, appears to use no additional flags
> cons: When swsusp stops using the flags, anti-frag takes them right back
> Makes anti-frag mutually exclusive with swsusp
>
> 2. Create a per-zone bitmap for every MAX_ORDER block
> pros: Straight-forward implementation initially
> cons: Needs resizing during hotadd which could get complicated
> Bit more cache pressure
>
> 3. Use the low two bits of page->lru
> pros: Uses existing struct page field
> cons: It's a bit funky looking
>
> 4. Use the page->flags of the struct page backing the pages used
> for the memmap.
> pros: Similar to the bitmap idea except with less hotadd problems
> cons: Bit more cache pressure
>
> 5. Add an additional field page->hintsflags used for non-critical flags.
> There are patches out there like guest page hinting that want to
> consume flags but not for any vital purpose and usually for machines
> that have ample amounts of memory. For these features, add an
> additional page->hintsflags
> pros: Straight-forward to implement
> cons: Increses struct page size for some kernel features.
>
> I am leaning towards option 3 because it uses no additional memory but I'm
> not sure how people feel about using pointer magic like this.
>
> Any opinions?
If, as you stated in a previous mail, you'd like to have flags per
MAX_ORDER block, you'd already have to suffer the extra cache pressure.
In that case I vote for 4.
Otherwise 3 sounds doable, we already hide PAGE_MAPPING_ANON in a
pointer, so hiding flags is not new to struct page. It's just a question
of how good the implementation will look, I hope you'll not have to
visit all the list ops.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
