Bill Davidsen wrote:
>
> On Mon, 12 Aug 2002, Helge Hafting wrote:
> > My office desktop machine (256M RAM) rarely swaps more than 10M
> > during work with 2.5.30. It used to go some 70M into swap
> > after a few days of writing, browsing, and those updatedb runs.
>
> Now tell us how someone who isn't a VM developer can tell if that's bad or
> good. Is it good because it didn't swap more than it needed to, or bad
> because there were more things it could have swapped to make more buffer
> room?
It feels more responsive too - which is no surprise. Like most users,
I don't _expect_ to wait for swapin when pressing a key or something.
Waiting for file io seems to be less of a problem, that stuff
_is_ on disk after all. I guess many people who knows a little about
computers feel this way. People that don't know what a "disk" is
may be different and more interested in total waiting.
On the serious side: vmstat provides more than swap info. It also
lists block io, where one might see if the block io goes up or down.
I suggest to find some repeatable workload with lots of file & swap
io, and see how much we get of each. My guess is that rmap
results in less io to to the same job. Not only swap io, but
swap+file io too. The design is more capable of selecting
the _right_ page to evict. (Assuming that page usage may
tell us something useful.) So the only questions left is
if the current implementation is good, and if the
improved efficiency makes up for the memory overhead.
>
> Serious question, tuning the -aa VM sometimes makes the swap use higher,
> even as the response to starting small jobs while doing kernel compiles or
> mkisofs gets better. I don't normally tune -ac kernels much, so I can't
> comment there.
Swap is good if there's lots of file io and
lots of unused apps sitting around. And bad if there's a large working
set and little _repeating_ file io. Such as the user switching between
a bunch of big apps working on few files. And perhaps some
non-repeating
io like updatedb or mail processing...
Helge Hafting
Helge Hafting
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Aug 15 2002 - 22:00:31 EST