On Thu, 28 Jan 1999 22:40:29 +0200, Nimrod Zimerman
<zimerman@deskmail.com> said:
> On Thu, Jan 28, 1999 at 06:16:35PM +0000, Stephen C. Tweedie wrote:
>> Fine, but vmstat alone means nothing in this respect, because the VM can
>> play a number of cunning tricks to keep the same swap page both on disk
>> and in memory. A large swap usage in vmstat doesn't tell us anything
>> about how fast things are moving. Wall clock time is the only reliable
>> benchmark here.
> It is hard to time these, as most of what I do isn't time critical (how can
> I time the amount of time it takes to respond to the up arrow in mutt?).
You can tell if it feels unresponsive. That is a valid observation, if
you can reproduce the environment exactly between boots to two separate
kernels and if the responsiveness is consistent.
> I can clearly see (using ps, vmstat and my HD light) that mutt gets swapped
> needlessly (when there is a 6mb cache) out of memory when doing something
> slightly memory intensive in another console - any allocation of "a lot" of
> memory would trigger this behavior.
Just because you don't understand the VM doesn't mean that this
behaviour is wrong! First of all, do you really see other kernels
behave differently? Do you have concrete numbers to back it up?
Secondly, cache is _necessary_ to the kernel. Every single program
running on your system works from it. To run a binary, or to load a
shared library, it first gets loaded into cache, and then the cache
memory is doubled-up as process virtual memory. Having 6M of cache
doesn't mean that the cache is just sitting there unused. In "free",
the "shared" field will tell you how much sharing there is between the
cache and other processes. If you have 6M cache and zero shared, then
yes, you have an excessive cache, but I doubt you will see that.
> Well, what I'm feeling is unneeded swapping, and what I'm seeing is
> something like this:
> (This happens when loading something).
> procs memory swap io system cpu
> r b w swpd free buff cache si so bi bo in cs us sy id
> 2 0 0 6456 312 136 5116 153 183 320 46 1339 153 24 12 64
> 2 0 0 6896 472 104 5324 217 232 217 69 1350 179 32 18 50
> ...
Looks fine to me. The buffer cache count is good and low. Since
buffers and cache are reclaimed by exactly the same loop in the VM, that
is a good indication that anything left in cache is actively in use by
the kernel.
--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.tux.org/lkml/