VM and swap - it's really unusable

2.4.17/18pre Martin Knoblauch 2 participants 2 messages Jan 14, 2002 – Jan 15, 2002

Share & tools

Martin Knoblauch

author

2002-01-14 16:25 UTC #0 lore raw

Quoted 13 lines

Re: [2.4.17/18pre] VM and swap - it's really unusable
Ken,
Attached is an update to my previous vmscan.patch.2.4.17.c
Version "d" fixes a BUG due to a race in the old code _and_ is much less agressive at cache_shrinkage or conversely more willing to swap out but not as much as the stock kernel.
It continues to work well wrt to high vm pressure.

Quoted 9 lines

Give it a whirl to see if it changes your "-j" symptoms.
If you like you can change the one line in the patch from "DEF_PRIORITY" which is "6" to progressively smaller values to "tune" whatever kind of swap_out behaviour you like.
Martin

Martin,

looking at the "d" version, I have one question on the piece that calls
swap_out:

@@ -521,6 +524,9 @@

        }
        spin_unlock(&pagemap_lru_lock);

+ if (max_mapped <= 0 && (nr_pages > 0 || priority <
DEF_PRIORITY))
+ swap_out(priority, gfp_mask, classzone);
+

        return nr_pages;

}

Curious on the conditions where swap_out is actually called, I added a
printk and found actaully cases where you call swap_out when nr_pages is already 0. What sense does that make? I would have thought that shrink_cache had done its job in that case.

shrink_cache: 24 page-request, 0 pages-to swap, max_mapped=-1599, max_scan=4350, priority=5
shrink_cache: 24 page-request, 0 pages-to swap, max_mapped=-487, max_scan=4052, priority=5
shrink_cache: 29 page-request, 0 pages-to swap, max_mapped=-1076, max_scan=1655, priority=5
shrink_cache: 2 page-request, 0 pages-to swap, max_mapped=-859, max_scan=820, priority=5

Martin

Signature · 5 lines

------------------------------------------------------------------
Martin Knoblauch         |    email:  [email protected]
TeraPort GmbH            |    Phone:  +49-89-510857-309
C+ITS                    |    Fax:    +49-89-510857-111
http://www.teraport.de   |    Mobile: +49-170-4904759

M.H.VanLeeuwen

2002-01-15 01:26 UTC #1 lore raw

Quoted 44 lines · Martin Knoblauch

Quoted 14 lines
Re: [2.4.17/18pre] VM and swap - it's really unusable
Ken,
Attached is an update to my previous vmscan.patch.2.4.17.c
Version "d" fixes a BUG due to a race in the old code _and_ is much less agressive at cache_shrinkage or conversely more willing to swap out but not as much as the stock kernel.
It continues to work well wrt to high vm pressure.
Quoted 9 lines
Give it a whirl to see if it changes your "-j" symptoms.
If you like you can change the one line in the patch from "DEF_PRIORITY" which is "6" to progressively smaller values to "tune" whatever kind of swap_out behaviour you like.
Martin
Martin,
looking at the "d" version, I have one question on the piece that calls
swap_out:
(quoted diff) +3 -0
@@ -521,6 +524,9 @@
        }
        spin_unlock(&pagemap_lru_lock);
 
+       if (max_mapped <= 0 && (nr_pages > 0 || priority <
 DEF_PRIORITY))
+               swap_out(priority, gfp_mask, classzone);
+
        return nr_pages;
 }
Curious on the conditions where swap_out is actually called, I added a
printk and found actaully cases where you call swap_out when nr_pages is already 0. What sense does that make? I would have thought that shrink_cache had done its job in that case.

Quoted 9 lines

shrink_cache: 24 page-request, 0 pages-to swap, max_mapped=-1599, max_scan=4350, priority=5
shrink_cache: 24 page-request, 0 pages-to swap, max_mapped=-487, max_scan=4052, priority=5
shrink_cache: 29 page-request, 0 pages-to swap, max_mapped=-1076, max_scan=1655, priority=5
shrink_cache: 2 page-request, 0 pages-to swap, max_mapped=-859, max_scan=820, priority=5

Martin,

The old kernel behavior was to call swapout as soon as max_mapped became zero and never finished shrinking cache upto nr_pages. This change adds some swap pressure back to the system based on the whether or not we managed to find nr_pages on the first (or subsequent) max_scan pages.

By changing DEF_PRIORITY in the above patch piece to a fixed value of 5, 4, or 3 you can see the affects of the change on the amount of swap used in my test case with a kernel build with various number of seti clients running.

A lower number means less swap pressure and more page cache shrinkage.

Martin

STOCK MH KERNEL.d MH KERNEL.d MH KERNEL.d MH KERNEL.d
prior = 5 prior = 4 prior = 3 prior = 2,1

CLEAN    1.1M         0.0M         0.0M         0.0M       not tested
CACHE    1.1M         0.0M         0.0M         0.0M       not tested
SETI 1   1.1M         0.8M         0.0M         0.0M       not tested
SETI 2   5.8M         2.5M         1.7M         1.0M       not tested
SETI 3  16.2M         4.2M         3.3M         1.9M       not tested
SETI 4  18.7M        10.5M         8.9M         4.8M       not tested
SETI 5  31.7M        15.3M        12.7M        12.0M       not tested
SETI 6  35.3M        25.4M        18.6M        18.2M       not tested
SETI 7  38.8M        37.7M        25.3M        27.2M       not tested