> Ok, this is due to having _only_ a time limit for kswapd - I've known all
> along that that was wrong, but it works for me with tons of memory, and I
> wanted to have people be able to actually compare. So the thing I'd like
> you to compare against and try is simply:
>
> mm/vmscan.c, around like 540:
>
> /* max one hundreth of a second */
> end_time = jiffies + (HZ-1)/100;
> do {
> if (!do_try_to_free_page(0))
> break;
> + if (nr_free_pages > 2*freepages.high)
> + break;
> } while (time_before_eq(jiffies,end_time));
>
> The reason you see the behaviour you do is that otherwise it will free up
> as much memory as it can in one hundreth of a second - which is fine if it
> has to do IO in order to free it up, but is bad if it can do it by just
> freeing cached pages..
Could this also explain something I'm seeing now for the first time?
I have 96M of ram in a machine, normally, it doesn't swap - however,
when doing something that excercises the buffer-cache, it starts
swapping stuff out (even though we don't actually have a memory
shortage).
In this instance, I was md5sum'ing some CD image files:
------- snip -------
[me:1] vomit:~$ free
total used free shared buffers cached
Mem: 95800 17444 78356 8336 5444 6012
-/+ buffers/cache: 5988 89812
Swap: 138780 0 138780
[me:1] vomit:~$ cd /mounts/scsi0/quake2/
[me:1] vomit:/mounts/scsi0/quake2$ md5sum *
e4c2b65c657fde7e01e6bda0dc95eac3 md5sums.txt
[...]
f9aa5d5d5f32eb8466f2ac66de519ab1 track_11.raw
[me:1] vomit:/mounts/scsi0/quake2$ free
total used free shared buffers cached
Mem: 95800 81152 14648 1352 4912 72968
-/+ buffers/cache: 3272 92528
Swap: 138780 2448 136332
------- snip -------
md5sum never grows very large, infact, during the process, its quite
small, only 124K or so.
Andi reported that his problems went away after a `make clean' so I
tried that - but still I see the same thing.
Anyhow... I'll try your patch and see if that helps, but in someways
the present behaviour is arguably the right thing; it's getting rid
of pages which aren't being used, swapping at gettys and infrequently
used bits of daemons, etc. -- but its a little too aggresive as the
swapping starts very early and hurts performance.
Moving unused or very infrequently used pages out to swap and growing
the buffer cache is IMO a good thing, but detecting what is indeed an
`infrequently' used page and not, say, a database going to sleep
duing a lunch break seems a tad non-trivial to me.
-cw
-cw
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/