linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* 2.4 VM question
@ 2001-03-03 10:40 David
  2001-03-04 11:14 ` [CFT] " Mike Galbraith
  0 siblings, 1 reply; 3+ messages in thread
From: David @ 2001-03-03 10:40 UTC (permalink / raw)
  To: Linux Kernel

Is there a particular reason why 2.4 insists on stuffing as much as 
possible into swap?

It's particularly frustrating to experience the slowdown and lag while 
the disk grinds.  I have 256M in this machine.  Right now I have 180+ 
megs free and I am 120 megs into swap.  Netscape and Mozilla are slow 
enough as it is without having to pull pages off the disk.  Running GIMP 
as well brings the system nearly to a crawl as I start opening up some 
large pictures.

Mind you however, I still have -plenty- of free memory in 
buffers/cache.  The filesystem is also reiserfs.

I would also like to point out that it's rather irritating to swapoff 
and basically everything flat out stalls until all the pages are back in 
memory.  It is also worthy of mention that it takes about 4 minutes to 
swapoff the first 64M file.  This is on a pIII 350.  The second 64M file 
took 5 minutes.

# uname -r
2.4.2-ac3

# free
            total       used       free     shared    buffers     cached
Mem:        253876     250360       3516          0      36448      86484
-/+ buffers/cache:     127428     126448
Swap:        65532      65496         36

# time swapoff /swapfile

real    5m21.080s
user    0m0.000s
sys     2m59.370s

Now that everything is forcibly paged back in, the system is once again 
responsive and quick.

Is there a particular VM quirk?  A bug?  As I see it there are two 
issues, a) the insistence of the kernel to page everything out, and b) 
the stall to page things back in, including the time frame.

-d


^ permalink raw reply	[flat|nested] 3+ messages in thread

* [CFT] Re: 2.4 VM question
  2001-03-03 10:40 2.4 VM question David
@ 2001-03-04 11:14 ` Mike Galbraith
  2001-03-16 22:17   ` X freeze/ kernel 4.2/ gnome/ alpha LX164 Mark Hansel
  0 siblings, 1 reply; 3+ messages in thread
From: Mike Galbraith @ 2001-03-04 11:14 UTC (permalink / raw)
  To: David; +Cc: Rik van Riel, Alan Cox, Linux Kernel

On Sat, 3 Mar 2001, David wrote:

> Is there a particular reason why 2.4 insists on stuffing as much as
> possible into swap?

Yes.. the VM is being tuned.  The latest changes result in overly
agressive caching with some work loads.

For people who are running into this, please edit mm/vmscan.c and
change DEF_PRIORITY from 6 to 2.  This change helps the performance
woes I see on my box quite a bit.  Report results to me (interested),
and the cc list (those who can ACT on it;) unless they say otherwise.

	-Mike


^ permalink raw reply	[flat|nested] 3+ messages in thread

* X freeze/ kernel 4.2/ gnome/ alpha LX164
  2001-03-04 11:14 ` [CFT] " Mike Galbraith
@ 2001-03-16 22:17   ` Mark Hansel
  0 siblings, 0 replies; 3+ messages in thread
From: Mark Hansel @ 2001-03-16 22:17 UTC (permalink / raw)
  To: Linux Kernel

Does this belong elsewhere? outline follows, details available.

I have a series of log entries that look like this:
	got res[xxxx:xxxx] for resource X of <device follows>

One device was the 21140 chip on my ethernet card. A few were for the
matrox video card.

Symptoms were frozen keyboard, but able to get in fro 2d system. X was
very busy (95% of CPU). Killed softare piece by piece with no change.
Killed gdm. No change.

Runlevel change to 5 got me into gnome, switching back to 3 got back the
frozen keyboard.

Reboot required.

mhansel
hansel@mnstate.edu



^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2001-03-16 22:18 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-03-03 10:40 2.4 VM question David
2001-03-04 11:14 ` [CFT] " Mike Galbraith
2001-03-16 22:17   ` X freeze/ kernel 4.2/ gnome/ alpha LX164 Mark Hansel

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).