[uClinux-dev] kswapd consumes 63% of cpu resources with ramfs

Peter Vandenabeele peter.vandenabeele at mind.be
Wed Mar 19 10:04:24 EST 2003


Hi,

We face this problem with uClinux 2.4.20 at one of our customer 
projects.

/proc> cat version
Linux version 2.4.20-uc0 (jt at srv003) (gcc version 2.95.3 20010315
(release)(ColdFire patches - 20010318 from
http://fiddes.net/coldfire/)(-msep-data patches)) #337 Wed Mar 19 15:48:08
CET 2003

With a patch made by Jean Pihet for "maxsize" for ramfs. This patch is 
attached. Standard instructions for applying are:

> To apply the ramfs patch, cd to the linux-2.4.x directory and type:
>  cat ramfs-2.4.20.patch.txt | patch -p 1

When the system starts initially, this is the /proc/meminfo

/> cat /proc/meminfo
        total:    used:    free:  shared: buffers:  cached: 
Mem:  63410176  2514944 60895232        0   159744   868352
Swap:        0        0        0
MemTotal:        61924 kB
MemFree:         59468 kB
MemShared:           0 kB
Buffers:           156 kB
Cached:            848 kB
SwapCached:          0 kB
Active:            156 kB
Inactive:          848 kB
HighTotal:           0 kB
HighFree:            0 kB
LowTotal:        61924 kB
LowFree:         59468 kB
SwapTotal:           0 kB
SwapFree:            0 kB
/>

After +/- 30 minutes, kswapd is using 29% cpu time.

/> ps
  PID PORT STAT  SIZE SHARED %CPU COMMAND
    1      S      29K     0K  0.1 init
    2      S       0K     0K  0.0 keventd
    3      R       0K     0K  0.0 ksoftirqd_CPU0
    4      R       0K     0K 29.0 kswapd
    5      S       0K     0K  0.0 bdflush
    6      S       0K     0K  0.0 kupdated
   21      S     170K     0K  0.1 /usr/bin/sockcom
   22      S     266K     0K  1.1 /usr/bin/vipcom
   23      S     214K     0K  3.8 /usr/bin/imglog
   24   S0 S      85K     0K  0.0 /usr/bin/keypad
   25      S      18K     0K  0.0 /bin/inetd
   26      S      37K     0K  0.0 /bin/boa
   27      S      17K     0K  0.0 /bin/flatfsd
   30   S0 S      25K     0K  0.0 /bin/sh
   32      S      25K     0K  0.2 /bin/telnetd
   33   p0 R      28K     0K  0.4 sh

This is the /proc/memfree after +/- 30 minutes, 

/> cat /proc/meminfo
        total:    used:    free:  shared: buffers:  cached:
Mem:  63410176 14237696 49172480        0   159744 12169216
Swap:        0        0        0
MemTotal:        61924 kB
MemFree:         48020 kB
MemShared:           0 kB
Buffers:           156 kB
Cached:          11884 kB
SwapCached:          0 kB
Active:            156 kB
Inactive:        11884 kB
HighTotal:           0 kB
HighFree:            0 kB
LowTotal:        61924 kB
LowFree:         48020 kB
SwapTotal:           0 kB
SwapFree:            0 kB

When it gest further, the system usage of kswapd further deteriorates. 
Below is the original problem statement we got.

> The RAMFS filesystem seems to work fine.  When the upper limit is reached
> then we get an error ENOSPC when we write to file.
>
> There is one issue left which we also had in the previous kernel (2.0.38):  
> the kswapd process is taking all the cpu time:
>
> /proc> ps
>   PID PORT STAT  SIZE SHARED %CPU COMMAND
>     1      S      29K     0K  0.1 init
>     2      S       0K     0K  0.0 keventd
>     3      R       0K     0K  0.0 ksoftirqd_CPU0
>     4      R       0K     0K 63.6 kswapd
>     5      S       0K     0K  0.0 bdflush
>     6      S       0K     0K  0.0 kupdated
>    22      S     174K     0K  1.3 /usr/bin/sockcom
>    23      S     266K     0K  4.5 /usr/bin/vipcom
>    24      S     214K     0K  8.3 /usr/bin/imglog
>    25      S     210K     0K  1.3 /usr/bin/proxy ttyS2
>    26      S     210K     0K  1.1 /usr/bin/proxy ttyS3
>    27   S0 S      85K     0K  0.0 /usr/bin/keypad
>    28      S      18K     0K  0.0 /bin/inetd
>    29      S      37K     0K  0.0 /bin/boa
>    30      S      17K     0K  0.0 /bin/flatfsd
>    33   S0 S      25K     0K  0.0 /bin/sh
>    34      S      25K     0K  0.0 /bin/telnetd
>    35   p0 R      28K     0K  0.0 sh
> /proc> cpu
> CPU:  busy 100%  (system=100% user=0% nice=0% idle=0%)
> 
> This occurs when the board is running for a while and makes 
> the serial communication and image capturing unreliable.

Sincerely,

Peter

--
Peter Vandenabeele
Mind: Embedded Linux and eCos Development -- http://mind.be



More information about the uClinux-dev mailing list