On 2/7/07, Christoph Lameter <[EMAIL PROTECTED]> wrote:
On Tue, 6 Feb 2007, Nate Diller wrote:
> > The dirty ratio with the ZVCS would be
> >
> > NR_DIRTY + NR_UNSTABLE_NFS
> > /
> > NR_FREE_PAGES + NR_INACTIVE + NR_ACTIVE + NR_MLOCK
>
> I don't understand why you want to account
On Tue, 6 Feb 2007, Nate Diller wrote:
> > The dirty ratio with the ZVCS would be
> >
> > NR_DIRTY + NR_UNSTABLE_NFS
> > /
> > NR_FREE_PAGES + NR_INACTIVE + NR_ACTIVE + NR_MLOCK
>
> I don't understand why you want to account mlocked pages in
> dirty_ratio. of course mlocked pages *can*
On Tue, 6 Feb 2007, Nate Diller wrote:
The dirty ratio with the ZVCS would be
NR_DIRTY + NR_UNSTABLE_NFS
/
NR_FREE_PAGES + NR_INACTIVE + NR_ACTIVE + NR_MLOCK
I don't understand why you want to account mlocked pages in
dirty_ratio. of course mlocked pages *can* be dirty,
On 2/7/07, Christoph Lameter [EMAIL PROTECTED] wrote:
On Tue, 6 Feb 2007, Nate Diller wrote:
The dirty ratio with the ZVCS would be
NR_DIRTY + NR_UNSTABLE_NFS
/
NR_FREE_PAGES + NR_INACTIVE + NR_ACTIVE + NR_MLOCK
I don't understand why you want to account mlocked pages in
On 2/4/07, Christoph Lameter <[EMAIL PROTECTED]> wrote:
On Sun, 4 Feb 2007, Arjan van de Ven wrote:
>
> > Exclusion or inclusion of NR_MLOCK number is straightforward for the dirty
> > ratio calcuations. global_page_state(NR_MLOCK) f.e. would get us totals on
> > mlocked pages per zone.
On 2/4/07, Christoph Lameter [EMAIL PROTECTED] wrote:
On Sun, 4 Feb 2007, Arjan van de Ven wrote:
Exclusion or inclusion of NR_MLOCK number is straightforward for the dirty
ratio calcuations. global_page_state(NR_MLOCK) f.e. would get us totals on
mlocked pages per zone.
Patch seems to work and survives AIM7. However, we only know about 30% of
the Mlocked pages after boot. With this additional patch to
opportunistically move pages off the LRU immediately I can get the counter
be accurate (for all practical purposes) like the non lazy version:
Index:
On Mon, 5 Feb 2007, Matt Mackall wrote:
> 2) lazy accounting - the same as above, with the work all moved to the
> LRU sweep
> 3) accounting with an extra page flag - still needs to scan VMAs on munmap
>
> Christoph seems to prefer the third.
No I am saying that 2 requires 3 to work reliably.
On Mon, 5 Feb 2007, Arjan van de Ven wrote:
> > I still need a solution for the problem of not having enough page flag
> > bits on i386 NUMA.
>
> I still don't get why you *really* need such a bit.
Because otherwise you cannot establish why a page was removed from the
LRU. If a page is off
On Mon, Feb 05, 2007 at 09:39:34AM +0100, Arjan van de Ven wrote:
> On Sun, 2007-02-04 at 23:57 -0800, Christoph Lameter wrote:
> > Hmmm.. I have had no time to test this one yet but I think this should
> > work. It uses the delayed method and a new page flag PageMlocked() with
> > different
On Sun, 2007-02-04 at 23:57 -0800, Christoph Lameter wrote:
> Hmmm.. I have had no time to test this one yet but I think this should
> work. It uses the delayed method and a new page flag PageMlocked() with
> different semantics. Fix for page migration is also included.
>
> Patch avoids to put
On Sun, 2007-02-04 at 23:57 -0800, Christoph Lameter wrote:
Hmmm.. I have had no time to test this one yet but I think this should
work. It uses the delayed method and a new page flag PageMlocked() with
different semantics. Fix for page migration is also included.
Patch avoids to put new
On Mon, Feb 05, 2007 at 09:39:34AM +0100, Arjan van de Ven wrote:
On Sun, 2007-02-04 at 23:57 -0800, Christoph Lameter wrote:
Hmmm.. I have had no time to test this one yet but I think this should
work. It uses the delayed method and a new page flag PageMlocked() with
different semantics.
On Mon, 5 Feb 2007, Arjan van de Ven wrote:
I still need a solution for the problem of not having enough page flag
bits on i386 NUMA.
I still don't get why you *really* need such a bit.
Because otherwise you cannot establish why a page was removed from the
LRU. If a page is off the LRU
On Mon, 5 Feb 2007, Matt Mackall wrote:
2) lazy accounting - the same as above, with the work all moved to the
LRU sweep
3) accounting with an extra page flag - still needs to scan VMAs on munmap
Christoph seems to prefer the third.
No I am saying that 2 requires 3 to work reliably. The
Patch seems to work and survives AIM7. However, we only know about 30% of
the Mlocked pages after boot. With this additional patch to
opportunistically move pages off the LRU immediately I can get the counter
be accurate (for all practical purposes) like the non lazy version:
Index:
Hmmm.. I have had no time to test this one yet but I think this should
work. It uses the delayed method and a new page flag PageMlocked() with
different semantics. Fix for page migration is also included.
Patch avoids to put new anonymous mlocked pages on the LRU. Maybe the same
could be done
On Sun, 4 Feb 2007, Arjan van de Ven wrote:
>
> > Exclusion or inclusion of NR_MLOCK number is straightforward for the dirty
> > ratio calcuations. global_page_state(NR_MLOCK) f.e. would get us totals on
> > mlocked pages per zone. node_page_state(NR_MLOCK) gives a node specific
> > number of
> Exclusion or inclusion of NR_MLOCK number is straightforward for the dirty
> ratio calcuations. global_page_state(NR_MLOCK) f.e. would get us totals on
> mlocked pages per zone. node_page_state(NR_MLOCK) gives a node specific
> number of mlocked pages. The nice thing about ZVCs is that it
Exclusion or inclusion of NR_MLOCK number is straightforward for the dirty
ratio calcuations. global_page_state(NR_MLOCK) f.e. would get us totals on
mlocked pages per zone. node_page_state(NR_MLOCK) gives a node specific
number of mlocked pages. The nice thing about ZVCs is that it allows
On Sun, 4 Feb 2007, Arjan van de Ven wrote:
Exclusion or inclusion of NR_MLOCK number is straightforward for the dirty
ratio calcuations. global_page_state(NR_MLOCK) f.e. would get us totals on
mlocked pages per zone. node_page_state(NR_MLOCK) gives a node specific
number of mlocked
Hmmm.. I have had no time to test this one yet but I think this should
work. It uses the delayed method and a new page flag PageMlocked() with
different semantics. Fix for page migration is also included.
Patch avoids to put new anonymous mlocked pages on the LRU. Maybe the same
could be done
On Sat, 3 Feb 2007, Andrew Morton wrote:
> Do we actually need NR_MLOCK? Page reclaim tends to care more about the
> size of the LRUs and doesn't have much dependency on ->present_pages,
Yes, we'd be fine with general reclaim I think. But the calculation of the
dirty ratio based on ZVCs would
On Sat, 3 Feb 2007 11:03:59 -0800 (PST) Christoph Lameter <[EMAIL PROTECTED]>
wrote:
> Here is the second piece removing mlock pages off the LRU during scanning.
> I tried moving them to a separate list but then we run into issues with
> locking. We do not need ithe list though since we will
Hi.
On Fri, 2007-02-02 at 22:20 -0800, Christoph Lameter wrote:
> 1. We use the 21st page flag and we only have 20 on 32 bit NUMA platforms.
If it will help, I now have an implementation of the dynamically
allocated pageflags code I've posted in the past that is NUMA aware.
It's not memory
Hi again.
On Sat, 2007-02-03 at 00:53 -0800, Andrew Morton wrote:
> > 1. We use the 21st page flag and we only have 20 on 32 bit NUMA platforms.
>
> Ow. How were you thinking of fixing that?
Oh, guess the dyn_pageflags patch is not needed then - the dangers of
replying before reading a whole
Here is the second piece removing mlock pages off the LRU during scanning.
I tried moving them to a separate list but then we run into issues with
locking. We do not need ithe list though since we will encounter the
page again anyways during zap_pte_range.
However, in zap_pte_range we then run
On Sat, 3 Feb 2007, Arjan van de Ven wrote:
> Well.. That's the point! Only IF there is a reclaim scan do you move
> them out again. The fact that these pages are on the list isn't a
> problem. The fact that you keep encountering them over and over again
> during *scanning* is. So Andrews
On Sat, 3 Feb 2007, Arjan van de Ven wrote:
> it's simpler. You only move them off when you encounter them during a
> scan. No walking early etc etc. Only do work when there is an actual
> situation where you do scan.
Yes but then you do not have an accurate count of MLOCKed pages. We will
only
On Sat, 2007-02-03 at 09:56 -0800, Christoph Lameter wrote:
> On Sat, 3 Feb 2007, Andrew Morton wrote:
>
> > I wonder if it can be simpler. Make two changes:
>
> Would be great if this could get simpler.
>
> > a) If the scanner encounters an mlocked page on the LRU, take it off.
>
> The
On Sat, 3 Feb 2007, Martin J. Bligh wrote:
> Doesn't matter - you can just do it lazily. If you find a page that is
> locked, move it to the locked list. when unlocking a page you *always*
> move it back to the normal list. If someone else is still locking it,
> we'll move it back to the lock
On Sat, 3 Feb 2007, Andrew Morton wrote:
> I wonder if it can be simpler. Make two changes:
Would be great if this could get simpler.
> a) If the scanner encounters an mlocked page on the LRU, take it off.
The current patch takes them off when mlock is set (which may not work
since the page
On Sat, 3 Feb 2007, Christoph Hellwig wrote:
> This patch seems to not handle the cases where more than one process mlocks
> a page and you really need a pincount in the page to not release it before
> all processes have munlock it or died. I did a similar patch a while
> ago and tried to handle
Christoph Hellwig wrote:
On Fri, Feb 02, 2007 at 10:20:12PM -0800, Christoph Lameter wrote:
This is a new variation on the earlier RFC for tracking mlocked pages.
We now mark a mlocked page with a bit in the page flags and remove
them from the LRU. Pages get moved back when no vma that
On Fri, Feb 02, 2007 at 10:20:12PM -0800, Christoph Lameter wrote:
> This is a new variation on the earlier RFC for tracking mlocked pages.
> We now mark a mlocked page with a bit in the page flags and remove
> them from the LRU. Pages get moved back when no vma that references
> the page has
On Fri, 2 Feb 2007 22:20:12 -0800 (PST) Christoph Lameter <[EMAIL PROTECTED]>
wrote:
> This is a new variation on the earlier RFC for tracking mlocked pages.
> We now mark a mlocked page with a bit in the page flags and remove
> them from the LRU. Pages get moved back when no vma that references
On Fri, 2 Feb 2007 22:20:12 -0800 (PST) Christoph Lameter [EMAIL PROTECTED]
wrote:
This is a new variation on the earlier RFC for tracking mlocked pages.
We now mark a mlocked page with a bit in the page flags and remove
them from the LRU. Pages get moved back when no vma that references
the
On Fri, Feb 02, 2007 at 10:20:12PM -0800, Christoph Lameter wrote:
This is a new variation on the earlier RFC for tracking mlocked pages.
We now mark a mlocked page with a bit in the page flags and remove
them from the LRU. Pages get moved back when no vma that references
the page has
Christoph Hellwig wrote:
On Fri, Feb 02, 2007 at 10:20:12PM -0800, Christoph Lameter wrote:
This is a new variation on the earlier RFC for tracking mlocked pages.
We now mark a mlocked page with a bit in the page flags and remove
them from the LRU. Pages get moved back when no vma that
On Sat, 3 Feb 2007, Christoph Hellwig wrote:
This patch seems to not handle the cases where more than one process mlocks
a page and you really need a pincount in the page to not release it before
all processes have munlock it or died. I did a similar patch a while
ago and tried to handle it
On Sat, 3 Feb 2007, Andrew Morton wrote:
I wonder if it can be simpler. Make two changes:
Would be great if this could get simpler.
a) If the scanner encounters an mlocked page on the LRU, take it off.
The current patch takes them off when mlock is set (which may not work
since the page
On Sat, 3 Feb 2007, Martin J. Bligh wrote:
Doesn't matter - you can just do it lazily. If you find a page that is
locked, move it to the locked list. when unlocking a page you *always*
move it back to the normal list. If someone else is still locking it,
we'll move it back to the lock list on
On Sat, 2007-02-03 at 09:56 -0800, Christoph Lameter wrote:
On Sat, 3 Feb 2007, Andrew Morton wrote:
I wonder if it can be simpler. Make two changes:
Would be great if this could get simpler.
a) If the scanner encounters an mlocked page on the LRU, take it off.
The current patch
On Sat, 3 Feb 2007, Arjan van de Ven wrote:
it's simpler. You only move them off when you encounter them during a
scan. No walking early etc etc. Only do work when there is an actual
situation where you do scan.
Yes but then you do not have an accurate count of MLOCKed pages. We will
only
On Sat, 3 Feb 2007, Arjan van de Ven wrote:
Well.. That's the point! Only IF there is a reclaim scan do you move
them out again. The fact that these pages are on the list isn't a
problem. The fact that you keep encountering them over and over again
during *scanning* is. So Andrews suggestion
Here is the second piece removing mlock pages off the LRU during scanning.
I tried moving them to a separate list but then we run into issues with
locking. We do not need ithe list though since we will encounter the
page again anyways during zap_pte_range.
However, in zap_pte_range we then run
Hi.
On Fri, 2007-02-02 at 22:20 -0800, Christoph Lameter wrote:
1. We use the 21st page flag and we only have 20 on 32 bit NUMA platforms.
If it will help, I now have an implementation of the dynamically
allocated pageflags code I've posted in the past that is NUMA aware.
It's not memory
Hi again.
On Sat, 2007-02-03 at 00:53 -0800, Andrew Morton wrote:
1. We use the 21st page flag and we only have 20 on 32 bit NUMA platforms.
Ow. How were you thinking of fixing that?
Oh, guess the dyn_pageflags patch is not needed then - the dangers of
replying before reading a whole
On Sat, 3 Feb 2007 11:03:59 -0800 (PST) Christoph Lameter [EMAIL PROTECTED]
wrote:
Here is the second piece removing mlock pages off the LRU during scanning.
I tried moving them to a separate list but then we run into issues with
locking. We do not need ithe list though since we will
On Sat, 3 Feb 2007, Andrew Morton wrote:
Do we actually need NR_MLOCK? Page reclaim tends to care more about the
size of the LRUs and doesn't have much dependency on -present_pages,
Yes, we'd be fine with general reclaim I think. But the calculation of the
dirty ratio based on ZVCs would
This is a new variation on the earlier RFC for tracking mlocked pages.
We now mark a mlocked page with a bit in the page flags and remove
them from the LRU. Pages get moved back when no vma that references
the page has VM_LOCKED set anymore.
This means that vmscan no longer uselessly cycles over
This is a new variation on the earlier RFC for tracking mlocked pages.
We now mark a mlocked page with a bit in the page flags and remove
them from the LRU. Pages get moved back when no vma that references
the page has VM_LOCKED set anymore.
This means that vmscan no longer uselessly cycles over
52 matches
Mail list logo
