VM question: side effect of not scanning Active pages?

VM question: side effect of not scanning Active pages?

[Benjamin Redelings I]

Hello,
	In both Andrea and Rik's VM, I have tried modifying try_to_swap_out so
that a page would be skipped if it is "active".  For example, I have
currently modified 2.4.13-pre2 by adding:

          if (PageActive(page))
                  return 0;

after testing the hardware referenced bit.  This was motivated by
sections of VM-improvement patches written by both Rik and Andrea.
	This SEEMS to increase performance, but it has another side effect.  The
RSS of unused daemons no longer EVER drops to 4k, which it does without
this modification.  The RSS does decrease (usually) to the value of
shared memory, but the amount of shared memory only gets down to about
200-300k instead of decreasing to 4k.
	Can anyone tell me why not scanning Active page for swapout would have
this effect?  Thanks!

-BenRI
-- 
"I will begin again" - U2, 'New Year's Day'
Benjamin Redelings I      <><     http://www.bol.ucla.edu/~bredelin/

VM question: side effect of not scanning Active pages?

[Benjamin Redelings I]

Hello,
	In both Andrea and Rik's VM, I have tried modifying try_to_swap_out so
that a page would be skipped if it is "active".  For example, I have
currently modified 2.4.13-pre2 by adding:

          if (PageActive(page))
                  return 0;

after testing the hardware referenced bit.  This was motivated by
sections of VM-improvement patches written by both Rik and Andrea.
	This SEEMS to increase performance, but it has another side effect.  The
RSS of unused daemons no longer EVER drops to 4k, which it does without
this modification.  The RSS does decrease (usually) to the value of
shared memory, but the amount of shared memory only gets down to about
200-300k instead of decreasing to 4k.
	Can anyone tell me why not scanning Active page for swapout would have
this effect?  Thanks!

-BenRI
-- 
"I will begin again" - U2, 'New Year's Day'
Benjamin Redelings I      <><     http://www.bol.ucla.edu/~bredelin/


--
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/

Re: VM question: side effect of not scanning Active pages?

[Joseph A Knapka]

Benjamin Redelings I wrote:
> 
> Hello,
>         In both Andrea and Rik's VM, I have tried modifying try_to_swap_out so
> that a page would be skipped if it is "active".  For example, I have
> currently modified 2.4.13-pre2 by adding:
> 
>           if (PageActive(page))
>                   return 0;
> 
> after testing the hardware referenced bit.  This was motivated by
> sections of VM-improvement patches written by both Rik and Andrea.
>         This SEEMS to increase performance, but it has another side effect.  The
> RSS of unused daemons no longer EVER drops to 4k, which it does without
> this modification.  The RSS does decrease (usually) to the value of
> shared memory, but the amount of shared memory only gets down to about
> 200-300k instead of decreasing to 4k.
>         Can anyone tell me why not scanning Active page for swapout would have
> this effect?  Thanks!

Well, you will never unmap active page. Essentially,
that means that once a page gets onto the active
list, it is effectively pinned in memory until all processes
using the page exit. This is probably not what you want.
You'll still see some pages get swapped out, of course,
because not all pages in use by processes live on the
active list (anonymous pages that have never been unmapped,
for example, don't, at least in the kernels I'm familiar
with; though I understand there's some talk of changing
that).

Cheers,

-- Joe
# "You know how many remote castles there are along the
#  gorges? You can't MOVE for remote castles!" - Lu Tze re. Uberwald
# Linux MM docs:
http://home.earthlink.net/~jknapka/linux-mm/vmoutline.html
--
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/

Re: VM question: side effect of not scanning Active pages?

[Joseph A Knapka]

Benjamin Redelings I wrote:
> 
> Hi Joe,
>         Thanks for the answer.
> 
> > Well, you will never unmap active page. Essentially,
> > that means that once a page gets onto the active
> > list, it is effectively pinned in memory until all processes
> > using the page exit.
> 
>         I'm not sure why this would be true.  Shouldn't any pages on the Active
> list be moved to the Inactive list eventually if they are not used?  In
> refill_inactive (vmscan.c), there is a loop over the active list with
> this code:
> 
>                  if (PageTestandClearReferenced(page)) {
>                          list_del(&page->lru);
>                          list_add(&page->lru, &active_list);
>                          continue;
>                  }
> 
>                  del_page_from_active_list(page);
>                  add_page_to_inactive_list(page);
> 
>         So, if the page is referenced, then it gets moved to the head of the
> active list, and the referenced bit cleared.  But if it is NOT marked
> referenced (which is what should happen for unused system daemons), then
> it should get added to the inactive list, right?
>         Please, let me know if I'm missing something :)

Well, that's what I get for reading 2.4.5 code :-) The active
list scanning used to check that a page was unreferenced by any
process PTEs before deactivating. Now that's unnecessary, since
it appears all the complicated machinery to support direct
reclaim of clean pages from the LRU has gone away, and
shrink_cache() nee page_launder() just directly frees
pages back into the free pool. Cool! So there's nothing
preventing mapped pages from being deactivated, which means
my previous assertion was just silly.

OK, here's what's happening, I think.  Bailing out of
try_to_swap_out() when a page is active simply prevents
active pages (eg, glibc pages) from being evicted from
a process's memory map. So even if the process isn't
using a page, any -other- process that's using it will
prevent it from being evicted from the VM of all the
other procs that have it mapped, whether they are using
the page or not. Presumably, RSS reflects the number
of pages a process has mapped, so you see your daemons
with big RSS because some other process is using their
pages. I don't know if that will cause problems at present
or not. I think accurate RSS figures would be necessary
for global kinds of VM balancing and control.

Cheers,

-- Joe
# "You know how many remote castles there are along the
#  gorges? You can't MOVE for remote castles!" - Lu Tze re. Uberwald
# Linux MM docs:
http://home.earthlink.net/~jknapka/linux-mm/vmoutline.html
--
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/

Re: VM question: side effect of not scanning Active pages?

[Jonathan Morton]

>	In both Andrea and Rik's VM, I have tried modifying try_to_swap_out so
>that a page would be skipped if it is "active".  For example, I have
>currently modified 2.4.13-pre2 by adding:
>
>          if (PageActive(page))
>                  return 0;
>
>after testing the hardware referenced bit.  This was motivated by
>sections of VM-improvement patches written by both Rik and Andrea.
>	This SEEMS to increase performance, but it has another side 
>effect.  The
>RSS of unused daemons no longer EVER drops to 4k, which it does without
>this modification.  The RSS does decrease (usually) to the value of
>shared memory, but the amount of shared memory only gets down to about
>200-300k instead of decreasing to 4k.
>	Can anyone tell me why not scanning Active page for swapout would have
>this effect?  Thanks!

The "active" pages in your inactive daemons are probably the glibc 
pages, which are generally in use by other applications.  It should 
not have any real effect on the system - in fact, keeping glibc in 
memory is probably a Good Thing, and may be partially responsible for 
your improvement in performance.

AFAICT, 'pinning' active pages in memory is a good thing, provided 
they are deactivated appropriately after a period of disuse.  This 
appears to be the case in current kernels and the new VM, so you're 
good to go in my view.

-- 
--------------------------------------------------------------
from:     Jonathan "Chromatix" Morton
mail:     chromi@cyberspace.org  (not for attachments)
website:  http://www.chromatix.uklinux.net/vnc/
geekcode: GCS$/E dpu(!) s:- a20 C+++ UL++ P L+++ E W+ N- o? K? w--- O-- M++$
           V? PS PE- Y+ PGP++ t- 5- X- R !tv b++ DI+++ D G e+ h+ r++ y+(*)
tagline:  The key to knowledge is not to rely on people to teach you it.

Re: VM question: side effect of not scanning Active pages?

[Jonathan Morton]

>	In both Andrea and Rik's VM, I have tried modifying try_to_swap_out so
>that a page would be skipped if it is "active".  For example, I have
>currently modified 2.4.13-pre2 by adding:
>
>          if (PageActive(page))
>                  return 0;
>
>after testing the hardware referenced bit.  This was motivated by
>sections of VM-improvement patches written by both Rik and Andrea.
>	This SEEMS to increase performance, but it has another side
>effect.  The
>RSS of unused daemons no longer EVER drops to 4k, which it does without
>this modification.  The RSS does decrease (usually) to the value of
>shared memory, but the amount of shared memory only gets down to about
>200-300k instead of decreasing to 4k.
>	Can anyone tell me why not scanning Active page for swapout would have
>this effect?  Thanks!

The "active" pages in your inactive daemons are probably the glibc
pages, which are generally in use by other applications.  It should
not have any real effect on the system - in fact, keeping glibc in
memory is probably a Good Thing, and may be partially responsible for
your improvement in performance.

AFAICT, 'pinning' active pages in memory is a good thing, provided
they are deactivated appropriately after a period of disuse.  This
appears to be the case in current kernels and the new VM, so you're
good to go in my view.

-- 
--------------------------------------------------------------
from:     Jonathan "Chromatix" Morton
mail:     chromi@cyberspace.org  (not for attachments)
website:  http://www.chromatix.uklinux.net/vnc/
geekcode: GCS$/E dpu(!) s:- a20 C+++ UL++ P L+++ E W+ N- o? K? w--- O-- M++$
           V? PS PE- Y+ PGP++ t- 5- X- R !tv b++ DI+++ D G e+ h+ r++ y+(*)
tagline:  The key to knowledge is not to rely on people to teach you it.

--
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/