[lkml]   [1997]   [Jul]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Time for a pre-patch-2.0.31-3? (buffer/cache patch included)
>> >     mm/vmscan.c 
> ...
> > change try_to_free_page() in some point to have a more aggressive

This version of try_to_free_page() is my own ... it's not in 2.1.xx.
The old version works like the agricultural three-filed system (with the
fields shrink_mmap, shm_swap, and swap_out). Only if current field fails
the switch to the next field follows ... a social behaviour. This is what
kswapd should do ... and kswapd has no problems if try_to_free_page()
fails. If a process needs a page the chance to get a free page is
higher in the next unused field ... this is what this version of
try_to_free_page() do if called with wait=1 ... an egoistic behaviour.

... just like in real life :-)

> > swapping strategy in low memory situations.
> > change in swap_tick(): wakeup kswapd more often in low memory
> > situations (adapted from 2.1.xx)
> ...
> These two changes from 2.1 wil kill machines that run out of swap/have
> slow processors - take a look at the changes I made to vmscan.c in
> for kswapd() and
> swap_tick() -- those changes should improve things on systems which
> swap a lot as they keep the swap more behaviour introduced in 2.1.3?,
> but try to be gentle and not eat 100% cpu when we do start swapping. Like
> I've said - it's a temporary fix until mm is reworked to be more
> deterministic.

Hmmm ... the only change in kswapd() I've done is:

while (1) {
kswapd_awake = 0;
current->signal = 0;
kswapd_awake = 1;
/* Do the background pageout: */
for (i=0; i < kswapd_ctl.maxpages; i++)
- try_to_free_page(GFP_KERNEL, 0, 0);
+ try_to_free_page(GFP_KERNEL, 0, (nr_free_pages < min_free_pages));

this should not be a problem, shouldn't it?

Only the change in swap_tick()

- next_swap_jiffies = jiffies + swapout_interval;
+ /* low on memory, we need to start swapping soon */
+ if(last_wakeup_low)
+ next_swap_jiffies = jiffies;
+ else
+ next_swap_jiffies = jiffies + swapout_interval;

may cause a problem. If I understand your hint correct, kswapd will be waked
up in a loop without running any other process if the last call can not free a
physical page due to a low swap space.

One question more: Does my version of try_to_free_page() run cause
any trouble with the version of your kswapd/swap_tick solution
given in


 \ /
  Last update: 2005-03-22 13:39    [W:0.147 / U:0.724 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site