kswapd is CPU-hungry (kernel 2.4.2-2)

kswapd is CPU-hungry (kernel 2.4.2-2)

[D Campbell]

after searching the archives i'm still a bit concerned
about the CPU usage of kswapd on a machine with lots of memory.

summary:  
kswapd at 66% CPU.  1G RAM.  ~800M taken by ramdisks.  no swap.

hardware:  
intel PIII-833 underclocked to 650
1G physical memory

memory config:
0.750 G ramdisk, ext2fs from an image, mounted as root
   64 M additional ramdisk, ramfs, mounted as /tmp
    8 M initrd, ext2fs from image, hangs around at /initrd

this should leave about 190M for applications and OS
to play with, even when /tmp is full.  it's running 
mysqld, sshd and a few simple data aquisition apps 
that use the SQL server.  no X, no sendmail, no
development envoronment.  intuitively, should be OK.

once booted, the machine runs with no physical drives
mounted.  there is no swap partition or file.

top reports kswapd taking about 2/3 of what should be
a fully loaded system.   

 12:15am  up 1 day,  6:20,  3 users,  load average: 4.04, 3.32, 2.92
58 processes: 54 sleeping, 4 running, 0 zombie, 0 stopped
CPU states:  0.0% user, 68.5% system, 31.3% nice,  0.0% idle
Mem:  1028808K av, 946404K used, 82404K free, 0K shrd, 794432K buff
Swap:       0K av,      0K used,     0K free            38256K cached

  PID USER     PRI  NI  SIZE  RSS SHARE STAT %CPU %MEM   TIME COMMAND
    4 root       9   0     0    0     0 SW   68.4  0.0  1155m kswapd  <-- 
 1265 root      20  19   244  244   168 R N  31.4  0.0 656:51 dnetc
    1 root       8   0   108  108    36 S     0.0  0.0   0:05 init

i understand that without swapspace, all kswapd
can do is knock bits of executables out of the program
memory so they have to be read again from the ramdisk.

nice idea, but in practice it's being done much more
aggressively than this user needs.  no need to spend
so much effort on keeping 80 M of RAM always free when 
nothing is likely to ask for that much.

the same kernel running on a more modest machine with
some real swap space is fine:

30 processes: 27 sleeping, 3 running, 0 zombie, 0 stopped
CPU states:  0.1% user,  0.3% system, 99.4% nice,  0.0% idle
Mem:   126568K av, 125072K used, 1496K free, 0K shrd, 16484K buff
Swap:    1976K av,      8K used, 1968K free           55392K cached

  PID USER     PRI  NI  SIZE  RSS SHARE STAT %CPU %MEM   TIME COMMAND
11348 root      20  19   520  520   444 R N  99.4  0.4 13820m dnetc
23571 root      11   0  1004 1004   812 R     0.5  0.7   0:00 top

has bigram/bigramdisk been addressed any differently/better
in 2.4.12 or earlier?

is there anything i can read from the machine to help show
someone familiar with the vm code where it's being goofy?

is there something i can tweak to change kswapd's goals?
/proc/sys/vm/freepages is read-only (mode 444) but the
others are tweakable.

grazzi mucho.

Duncan.  ( will search archives for replies, cc is welcome. )

__________________________________________________
Do You Yahoo!?
Make a great connection at Yahoo! Personals.
http://personals.yahoo.com

Re: kswapd is CPU-hungry (kernel 2.4.2-2)

[Robert Love]

On Sat, 2001-10-20 at 22:34, D Campbell wrote:
> after searching the archives i'm still a bit concerned
> about the CPU usage of kswapd on a machine with lots of memory.

a lot of VM work has been done, in particular to solve your problem. 
Two solutions have emerged, one in Alan's tree and one in Linus's.

I suggest you try one (or -- even better -- both).  I would be surprised
if your problem wasn't fixed.  The newest release in Alan's tree is
2.4.12-ac3 and it is running great here.  Linus has released a
2.4.13-pre5.

	Robert Love

Re: kswapd is CPU-hungry (kernel 2.4.2-2)

[Rik van Riel]

On Sat, 20 Oct 2001, D Campbell wrote:

> after searching the archives i'm still a bit concerned
> about the CPU usage of kswapd on a machine with lots of memory.
>
> summary:
> kswapd at 66% CPU.  1G RAM.  ~800M taken by ramdisks.  no swap.

OK, I think the problem is that the system allocates so much
highmem pages for the ramdisk that it's become impossible for
kswapd to ever meet the free target.

I _think_ this has been fixed in a more recent -ac kernel,
but haven't tested it with such a huge ramdisk...

If it is possible, could you test 2.4.12-ac3 ?
(if it's still broken, I'll go fix it)

regards,

Rik
-- 
DMCA, SSSCA, W3C?  Who cares?  http://thefreeworld.net/  (volunteers needed)

http://www.surriel.com/		http://distro.conectiva.com/