Hot/cold allocation -- swsusp can not handle hot pages

Hot/cold allocation -- swsusp can not handle hot pages

Post by Pavel Mache » Sun, 03 Nov 2002 20:30:23



Hi!

Swsusp counts free pages, and relies on fact that when it allocates
page there's one free page less. That is no longer true with hot
pages.

I attempted to work it around but it seems I am getting hot pages even
when I ask for cold one. This seems to fix it. Does it looks like
"possibly mergable" patch?

                                                                        Pavel

--- clean/kernel/suspend.c      2002-11-01 00:37:42.000000000 +0100

        pagedir_order = get_bitmask_order(SUSPEND_PD_PAGES(nr_copy_pages));

-       p = pagedir = (suspend_pagedir_t *)__get_free_pages(GFP_ATOMIC, pagedir_order);
+       p = pagedir = (suspend_pagedir_t *)__get_free_pages(GFP_ATOMIC | __GFP_COLD, pagedir_order);
        if(!pagedir)
                return NULL;

                SetPageNosave(page++);

        while(nr_copy_pages--) {
-               p->address = get_zeroed_page(GFP_ATOMIC);
+               p->address = get_zeroed_page(GFP_ATOMIC | __GFP_COLD);
                if(!p->address) {
                        free_suspend_pagedir((unsigned long) pagedir);
                        return NULL;
                }
                SetPageNosave(virt_to_page(p->address));
                p->orig_address = 0;
                p++;
--- clean/mm/page_alloc.c       2002-11-01 00:37:44.000000000 +0100

        unsigned long flags;
        struct page *page = NULL;

-       if (order == 0) {
+       if ((order == 0) && !cold) {
                struct per_cpu_pages *pcp;

                pcp = &zone->pageset[get_cpu()].pcp[cold];

--
Worst form of spam? Adding advertisment signatures ala sourceforge.net.
What goes next? Inserting advertisment *into* email?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

Hot/cold allocation -- swsusp can not handle hot pages

Post by William Lee Irwin II » Sun, 03 Nov 2002 20:50:10



> Swsusp counts free pages, and relies on fact that when it allocates
> page there's one free page less. That is no longer true with hot
> pages.
> I attempted to work it around but it seems I am getting hot pages even
> when I ask for cold one. This seems to fix it. Does it looks like
> "possibly mergable" patch?
> --- clean/mm/page_alloc.c  2002-11-01 00:37:44.000000000 +0100
> +++ linux-swsusp/mm/page_alloc.c   2002-11-01 22:53:47.000000000 +0100

>    unsigned long flags;
>    struct page *page = NULL;

> -  if (order == 0) {
> +  if ((order == 0) && !cold) {
>            struct per_cpu_pages *pcp;

>            pcp = &zone->pageset[get_cpu()].pcp[cold];

This doesn't seem to be doing what you want, even if it seems to work.
If you want there to be one free page less, then allocating it will
work regardless. What are you looking for besides that? If it's not
already working you want some additional semantics. Could this involve
is_head_of_free_region()? That should be solvable with a per-cpu list
shootdown algorithm to fully merge all the buddy bitmap things.

Bill
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

Hot/cold allocation -- swsusp can not handle hot pages

Post by Pavel Mache » Sun, 03 Nov 2002 22:30:12


Hi!

> > Swsusp counts free pages, and relies on fact that when it allocates
> > page there's one free page less. That is no longer true with hot
> > pages.
> > I attempted to work it around but it seems I am getting hot pages even
> > when I ask for cold one. This seems to fix it. Does it looks like
> > "possibly mergable" patch?
> > --- clean/mm/page_alloc.c     2002-11-01 00:37:44.000000000 +0100
> > +++ linux-swsusp/mm/page_alloc.c      2002-11-01 22:53:47.000000000 +0100

> >       unsigned long flags;
> >       struct page *page = NULL;

> > -     if (order == 0) {
> > +     if ((order == 0) && !cold) {
> >               struct per_cpu_pages *pcp;

> >               pcp = &zone->pageset[get_cpu()].pcp[cold];

> This doesn't seem to be doing what you want, even if it seems to work.
> If you want there to be one free page less, then allocating it will
> work regardless. What are you looking for besides that? If it's not
> already working you want some additional semantics. Could this involve
> is_head_of_free_region()? That should be solvable with a per-cpu list
> shootdown algorithm to fully merge all the buddy bitmap things.

I need pages I allocate to disappear from "is_head_of_free_region()",
so my counts match.

                                                                Pavel
--
Casualities in World Trade Center: ~3k dead inside the building,
cryptography in U.S.A. and free speech in Czech Republic.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

Hot/cold allocation -- swsusp can not handle hot pages

Post by William Lee Irwin II » Mon, 04 Nov 2002 22:20:12



>> I'm not really sure what to suggest here.  Emptying the per-cpu
>> page pools would be tricky.  Maybe a swsusp-special page allocator
>> which goes direct to the buddy lists or something.

> Well, see the patch above. That seems to do the trick for
> me. It seems that even "cold" allocation can give page from per-cpu
> pool. I thought that was a bug?

Not a bug. The semantics only imply a preference for merging, not
a requirement to do so. A direct dequeue-from-buddy method either
by adjusting watermarks or a specialized interface in combination
with per-cpu list shootdown is required to enforce your invariants.

Bill
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

Hot/cold allocation -- swsusp can not handle hot pages

Post by Andrew Morto » Mon, 04 Nov 2002 22:30:09



> ...
> "big-picture" should be in Documentation/swsusp.txt...

> *Should* be :-(. I need to copy all used memory, to make sure my
> snapshot is atomic.

> Copying works by looking at what is allocated, counting needed pages,
> allocating 'directory' for them, allocating memory for copies, and
> actually copying.

Ah.  I see.

Quote:> When I suddenly find I have less data to copy than I thought, it
> screws up the code.

Having a less-than-expected amount to copy sounds like it can
be safely handled?

Quote:> > I'm not really sure what to suggest here.  Emptying the per-cpu
> > page pools would be tricky.  Maybe a swsusp-special page allocator
> > which goes direct to the buddy lists or something.

> Well, see the patch above. That seems to do the trick for
> me. It seems that even "cold" allocation can give page from per-cpu
> pool. I thought that was a bug?

There are two queues per cpu.  cache-warm pages and cache-cold
pages.  The cold queue is mainly for lock amortisation, to avoid
taking the zone lock once per page.  But we can also allocate
from the cold queue for situations where we'll be invalidating the
cache anyway (file readahead).  We don't want to waste cache-hot
pages.  Your change breaks that.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
 
 
 

Hot/cold allocation -- swsusp can not handle hot pages

Post by William Lee Irwin II » Mon, 04 Nov 2002 23:30:10



Quote:> static void empty_pageset(struct zone *zone, struct per_cpu_pages *pcp)
> {
>    pcp->batch = pcp->low = pcp->high = 1;
>    pcp->count -= free_pages_bulk(zone, pcp->batch, &pcp->list, 0);
> }

Should be
        pcp->count -= free_pages_bulk(zone, pcp->count, &pcp->list, 0);

Bill
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/