[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: bdflush or others affecting disk cache



> Because it's more efficient to use swap space to hold stuff from RAM
> that is not currently being used.

But that means the Kernel is making the assumption it can cache the swap
data more efficiently than just putting that data in RAM as the software
requests?

I'd take a whack at this and would think that cache misses would result in
lower performance at this?

> Linux will happily shift process memory into swap to make more room for
> buffers. Why keep 100M worth of not-currently-active daemon in RAM when
> there is a process trying to buffer the whole disk?

I agree... but the swap space usage is constantly changing... so I guess
that means VM is making a poor decision as to what is
"not-currently-active"... swapping out stuff that then needs to be read
back or written, causing the disk thrashing?


> > Wouldn't it be far, FAR faster for the system to reduce the cache by
about
> > 100Mb or so instead of swapping that 100Mb to disk? And note that the
swap
>
> No. It is faster to use that memory for buffers if the system is being
> disk bound.

Well, it is being disk bound because it is constantly using swap...
causing it to be disk bound... causing the system to increase cache
size... causing more swap usage... etc. Anyone see this before?


----- Original Message ----- 
From: "Donovan Baarda" <abo@minkirri.apana.org.au>
To: "Jason Lim" <maillist@jasonlim.com>
Cc: <debian-isp@lists.debian.org>
Sent: Monday, April 19, 2004 08:28 AM
Subject: Re: bdflush or others affecting disk cache


> On Mon, 2004-04-19 at 09:31, Jason Lim wrote:
> > Hi all,
> >
> > I've been banging my head on this one for a while now on a 2.4.20
system.
> [...]
> > The problem is that swap usage can grow to 100Mb... yet the buffers
and
> > cache remain at astoundingly high levels.
> >
> > I can actually see memory to cache and buffers increasing and at the
same
> > time see it increasing swap usage!
> >
> > What I don't get is why the system... with about 700Mb in cache and
70Mb
> > in buffers, is using swap space at all.
> [...]
>
> Because it's more efficient to use swap space to hold stuff from RAM
> that is not currently being used.
>
> Linux will happily shift process memory into swap to make more room for
> buffers. Why keep 100M worth of not-currently-active daemon in RAM when
> there is a process trying to buffer the whole disk?
>
> > Wouldn't it be far, FAR faster for the system to reduce the cache by
about
> > 100Mb or so instead of swapping that 100Mb to disk? And note that the
swap
>
> No. It is faster to use that memory for buffers if the system is being
> disk bound.
>
> > usage is constantly fluctuating, so you can see the performance
problem
> > this is causing. Any ideas?!
>
> The VM management code in Linux is something that is constantly getting
> tweaked and re-written. 2.4.20 is quite old now, and it wouldn't
> surprise me if the current 2.4.26 kernel has had the VM significantly
> improved since then.
>
> The performance hits you are seeing are probably because a process is
> walking through the disk. The 2.4.20 VM system may not be handling it as
> gracefully as it could, but I bet there is a process doing heaps of disk
> reads that is triggering it.
>
> -- 
> Donovan Baarda <abo@minkirri.apana.org.au>
> http://minkirri.apana.org.au/~abo/
>
>
> -- 
> To UNSUBSCRIBE, email to debian-isp-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
listmaster@lists.debian.org
>
>



Reply to: