Re: wild imbalance in kswapd state

Stephen C. Tweedie (sct@redhat.com)
Thu, 23 Jul 1998 17:39:23 +0100


Hi,

On Mon, 20 Jul 1998 16:04:52 -0400, Bill Hawes <whawes@star.net> said:

> I'm trying to figure out how to restore performance for repeated
> page-cache intensive operations, and tried instrumenting the state
> transitions in do_try_to_free_page.

> The results were pretty interesting -- once the swapping starts, it
> stays parked in the shrink_mmap state until almost all of the page cache
> is gone.

Yep. All the benchmarking on machines <=16MB shows that this is
required behaviour or performance sinks like a rock.

> I'm currently experimenting with a patch that sets a maximum number of
> successes (e.g. 100) for the swap state and then forces a transition.
> Have others experimented with something like this and have any pros/cons
> to mention?

Yes. When doing the original kswap code, I spent ages experimenting
with a number of different algorithms which forced rotations between
states according to various different criteria. I found that on low
memory, at least, it didn't work: either you rapidly ended up back in
shrink_mmap() state and there was no effect, or you spent too much time
in other states and performance dropped severely.

It may be reasonable to allow the user to tune the behaviour to allow
more caching on larger memory machines, but when memory gets low, being
aggressive on the caches definitely appears to be the right thing to
do.

--Stephen

-
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.altern.org/andrebalsa/doc/lkml-faq.html