use-once-cleanup testing

DISCUSSION Marcelo Tosatti 5 participants 7 messages Jan 14, 2006 – Jan 16, 2006 Memory management

Share & tools

Marcelo Tosatti

author

2006-01-14 00:05 UTC #0 lore raw

Hi folks,

Rik's use-once cleanup patch (1) gets rid of a nasty problem. The use-once logic does not work for mmaped() files, due to the questionable assumption that any referenced pages of such files should be held in memory:

1 - http://lwn.net/Articles/134387/

static int shrink_list(struct list_head *page_list, struct scan_control *sc) {
...

                referenced = page_referenced(page, 1);
                /* In active use or really unfreeable?  Activate it. */
                if (referenced && page_mapping_inuse(page))
                        goto activate_locked;

The page activation scheme relies on mark_page_accessed() (exported function) to do the list move itself, which is the only way for in-cache non mapped pages to be promoted to the active list.

Rik's patch instead only sets the referenced bit at mark_page_accessed(), changing the use-once logic to work by means of a newly created PG_new flag. The flag, set at add_to_pagecache() time, gives pages a second round on the inactive list in case they get referenced. Page activation is then performed if the page is re-referenced.

Another clear advantage of not doing the list move at mark_page_accessed() time is decreased zone->lru_lock contention and cache thrashing in general (profiling on SMP machines would be interesting).

A possibly negative side-effect of PG_new, already mentioned by Nikita in this list, is that used-once pages lurk around longer in cache, which can slowdown particular workloads (it should not be hard to create such loads).

However, the ongoing non-resident book keeping implementation makes it possible to completly get rid of "second chance" behaviour: re-accessed evicted pages are automatically promoted to the active list.

For example this is a real scenario where use-once mmap() is performed:
http://www.uwsg.iu.edu/hypermail/linux/kernel/0109.2/0078.html

Patch being used for the tests is:
http://programming.kicks-ass.net/kernel-patches/page-replace/2.6.16-rc1/use_once-cleanup.patch

And here are results of larger than RAM sequential access with mmap():

2.6-git-jan-12:

        Command being timed: "iozone -B -s 143360 -i 1 -i 1 -i 1 -i 1 -w"
        Percent of CPU this job got: 6%
        Elapsed (wall clock) time (h:mm:ss or m:ss): 0:34.74

2.6-git-jan-12+useonce:

        Command being timed: "iozone -B -s 143360 -i 1 -i 1 -i 1 -i 1 -w"
        Percent of CPU this job got: 13%
        Elapsed (wall clock) time (h:mm:ss or m:ss): 0:16.22

And a few graphs of the active/inactive sizes with both read and mmap mode, with the vanilla and use-once patched kernels:

http://hera.kernel.org/~marcelo/mm/iozone_useonce/iozone_useonce.html

Its possible to note that even using read() the vanilla VM moves used-once pages to the active list (ie. the logic is not working as expected).

I would vote for inclusion of the first version of use-once-cleanup (without the arguable refill_inactive_zone() page_referenced change) into -mm.

Comments?

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Nick Piggin

2006-01-14 04:52 UTC #1 lore raw

Quoted 21 lines · Marcelo Tosatti

Hi folks,
Rik's use-once cleanup patch (1) gets rid of a nasty problem. The use-once logic does not work for mmaped() files, due to the questionable assumption that any referenced pages of such files should be held in memory:
1 - http://lwn.net/Articles/134387/
static int shrink_list(struct list_head *page_list, struct scan_control *sc) {
...
               referenced = page_referenced(page, 1);
               /* In active use or really unfreeable?  Activate it. */
               if (referenced && page_mapping_inuse(page))
                       goto activate_locked;
The page activation scheme relies on mark_page_accessed() (exported function) to do the list move itself, which is the only way for in-cache non mapped pages to be promoted to the active list.

Quoted 8 lines

Rik's patch instead only sets the referenced bit at mark_page_accessed(), changing the use-once logic to work by means of a newly created PG_new flag. The flag, set at add_to_pagecache() time, gives pages a second round on the inactive list in case they get referenced. Page activation is then performed if the page is re-referenced.

This is what I've done too (though I prefer a PG_useonce flag which gets set after they're first seen referenced).

I think Wu may also be doing something like it for adaptive readahead.

Basically: it has been reinvented so many times that it *has* to be a good idea ;)

Quoted 4 lines

Another clear advantage of not doing the list move at mark_page_accessed()
time is decreased zone->lru_lock contention and cache thrashing in general (profiling on SMP machines would be interesting).

It also allows one to get rid of the dirty hacks in mark_page_accessed callers and means read() based useonce actually works properly in cases where userspace isn't working in blocks of PAGE_SIZE (rsync I think was one that did this, with fairly horrible results).

Quoted 6 lines

A possibly negative side-effect of PG_new, already mentioned by Nikita in this list, is that used-once pages lurk around longer in cache, which can slowdown particular workloads (it should not be hard to create such loads).

Yes, I found that also doing use-once on mapped pages caused fairly huge slowdowns in some cases. File IO could much more easily cause X and its applications to get swapped out.

Quoted 5 lines

However, the ongoing non-resident book keeping implementation makes it possible to completly get rid of "second chance" behaviour: re-accessed evicted pages are automatically promoted to the active list.

Possibly. I think moving unmapped use-once over to PG_useonce first, and tidying the weird warts and special cases (that don't make sense) from vmscan is a good first step.

Unfortunately I don't think Andrew wants a bar of any of it. Nor would a crazy rewrite-pagereclaim tree really get any sort of testing at all, realistically :(

Ideas?

Marcelo Tosatti

author

2006-01-14 04:53 UTC #2 lore raw

Hi Nick,

Quoted 34 lines · Nick Piggin

Quoted 22 lines · Marcelo Tosatti
Hi folks,
Rik's use-once cleanup patch (1) gets rid of a nasty problem. The use-once logic does not work for mmaped() files, due to the questionable assumption that any referenced pages of such files should be held in memory:
1 - http://lwn.net/Articles/134387/
static int shrink_list(struct list_head *page_list, struct scan_control *sc)
{
...
              referenced = page_referenced(page, 1);
              /* In active use or really unfreeable?  Activate it. */
              if (referenced && page_mapping_inuse(page))
                      goto activate_locked;
The page activation scheme relies on mark_page_accessed() (exported function) to do the list move itself, which is the only way for in-cache non mapped pages to be promoted to the active list.
Quoted 8 lines
Rik's patch instead only sets the referenced bit at mark_page_accessed(), changing the use-once logic to work by means of a newly created PG_new flag. The flag, set at add_to_pagecache() time, gives pages a second round on the inactive list in case they get referenced. Page activation is then performed if the page is re-referenced.

Quoted 7 lines

This is what I've done too (though I prefer a PG_useonce flag which gets set after they're first seen referenced).
I think Wu may also be doing something like it for adaptive readahead.
Basically: it has been reinvented so many times that it *has* to be a good idea ;)

For most mixed loads, think so. But not for all certainly.

Quoted 31 lines

Quoted 5 lines
Another clear advantage of not doing the list move at mark_page_accessed() time is decreased zone->lru_lock contention and cache thrashing in general (profiling on SMP machines would be interesting).
It also allows one to get rid of the dirty hacks in mark_page_accessed callers and means read() based useonce actually works properly in cases where userspace isn't working in blocks of PAGE_SIZE (rsync I think was one that did this, with fairly horrible results).
Quoted 6 lines
A possibly negative side-effect of PG_new, already mentioned by Nikita in this list, is that used-once pages lurk around longer in cache, which can slowdown particular workloads (it should not be hard to create such loads).
Yes, I found that also doing use-once on mapped pages caused fairly huge slowdowns in some cases. File IO could much more easily cause X and its applications to get swapped out.
Quoted 5 lines
However, the ongoing non-resident book keeping implementation makes it possible to completly get rid of "second chance" behaviour: re-accessed evicted pages are automatically promoted to the active list.
Possibly. I think moving unmapped use-once over to PG_useonce first, and tidying the weird warts and special cases (that don't make sense) from vmscan is a good first step.

Quoted 5 lines

Unfortunately I don't think Andrew wants a bar of any of it. Nor would a crazy rewrite-pagereclaim tree really get any sort of testing at all, realistically :(
Ideas?

I think that creating a page replacement interface used by the VM to hide the details of the reclaim specifics is an important step forward, allowing co-existance of different replacement policies.

It opens up many possibilities.

Peter started the abstraction of the page reclaim code for his CLOCK-Pro implementation, and I've been working with him to improve it.

The current code is logically glued together, there is no distiction between reclaim cache interface and LRU: they are the same.

Please take a look at
http://programming.kicks-ass.net/kernel-patches/page-replace/2.6.16-rc1/page-replace-documentation.patch
and the related patches in that directory.

Its basically separating the actions invoked by generic VM:

- book keeping of page information (insertion, deletion, reference, and so on).
- selection of pagecache candidates for eviction

And:
- balancing between slab/pagecache eviction
- page eviction
- page writeout

IMO they should all be separate, with shared helpers functions, as the document and patches suggest.

The current set makes the traditional LRU 2-queue and CLOCK-Pro policies co-exist (at the very moment it contains several patches which change behaviour such as Rik's PG_new, Wu's zone scanning balancing, but they are not necessarily related to this).

Peter Zijlstra

2006-01-14 08:44 UTC #3 lore raw

In reply to Nick Piggin

Quoted 4 lines · Nick Piggin

Unfortunately I don't think Andrew wants a bar of any of it. Nor would a crazy rewrite-pagereclaim tree really get any sort of testing at all, realistically :(

Both HP and SGI have shown interrest in getting these patches in shape and testing them, so I do think there is quite some interrest in them.

I admit that there is still a lot of work to do, like getting the CART policies into the new tree and NUMAfying the CLOCK-Pro and CART policies. And ofcourse rigourous testing.

Andrew, what would you need on top of that to start being interrested?

Kind regards,

PeterZ

Andrew Morton

2006-01-14 08:51 UTC #4 lore raw

Quoted 3 lines · Peter Zijlstra

Andrew, what would you need on top of that to start being interrested?

A demonstration that the code will make sufficient improvement to justify its inclusion, naturally ;)

Speedups should outweigh the slowdowns, no really bad corner cases.

Rik van Riel

2006-01-16 13:06 UTC #5 lore raw

Quoted 1 line · Andrew Morton

Speedups should outweigh the slowdowns, no really bad corner cases.

When it comes to corner cases, clock-pro gets my vote over any of the alternative algorithms.

Signature · 7 lines

All Rights Reversed

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [email protected].  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Rik van Riel

2006-01-16 13:05 UTC #6 lore raw

In reply to Nick Piggin

Quoted 3 lines · Nick Piggin

Yes, I found that also doing use-once on mapped pages caused fairly huge slowdowns in some cases. File IO could much more easily cause X and its applications to get swapped out.

We can get rid of that effect easily by adding reclaim_mapped logic to the inactive list scan. The zone previous_priority will keep track of what to do when we start a scan...

Quoted 3 lines

Possibly. I think moving unmapped use-once over to PG_useonce first, and tidying the weird warts and special cases (that don't make sense) from vmscan is a good first step.

Agreed, cleaning up the code first will make it a lot easier to make improvements bit by bit.

Signature · 7 lines

All Rights Reversed

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [email protected].  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>