[lkml]   [2001]   [Dec]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: minimizing swap usage
On Thursday 27 December 2001 08:15 am, vda wrote:
> On Thursday 27 December 2001 09:47, christian e wrote:
> > > I've just installed 2.4.17 and so far it seems better.According
> > > to changelog there has been some changes to swap behaviour.Can I
> > > make it even more aggressive to cut down on buffers+cache somehow
> > > ??
> >
> > sorry ,my bad.After using it for some hours it's just as
> > bad.Rechecked the changelog and it was already done in the previous
> > kernel i used (17-rc1 ).Same problem with lots of cache and plenty
> > of swapping :-(
> Ok, let's try to collect some data.
> I ask (knowledgeable) list members to say whether they see something
> unusual
> You may find below
> 1) top of my box running normally
> 2) top after killall5 -15; killall5 -9
> 3) /proc/mounts
> Why proc/mounts? There you will see that my box is exclusively NFSed.
> AFAIK nfs mounts do not cache large amounts of data on the client
> size. Note that when you try to explain top (2).

You're not understanding. This is not a bug. This is intended behavior.
The problem is that this behavior is not neccisarily desirable. I have
attempted to propose something that can be TRIED in order to attempt to
optimize swap behavior for certain situations, primarily desktop usage.

This is not a bug.
There is nothing unusual about it.
I am not attempting to report a bug.
There is no need to collect data.
We have all the data we need from any number of complaints about
current swap behavior.
Something needs to be tried, I proposed something to be tried, I did
not report a bug, I did not say this was unusual for 2.4.x series.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:14    [W:0.065 / U:3.912 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site