We've configured in the more frugal page_alloc2() allocator and have noticed
that the CPU time of kswapd has jumped considerably.
A typical ps now shows something like this:
/> ps
PID PORT STAT SIZE SHARED %CPU COMMAND
1 S 94K 0K 0.0 /bin/init
2 S 0K 0K 0.0 keventd
3 R 0K 0K 0.6 ksoftirqd_CPU0
4 R 0K 0K 66.5 kswapd
5 S 0K 0K 0.0 bdflush
6 S 0K 0K 0.0 kupdated
24 S 29K 0K 0.0 dhcpcd -D -H -p -a eth0
56 S 42K 0K 0.0 portmap
63 S 0K 0K 0.0 rpciod
70 S 154K 4K 0.0 msh /etc/rdate.msh 10.0.0.118
72 S 154K 4K 0.0 msh /etc/scand.msh
76 S0 S 26K 4K 0.0 /bin/sh
77 S 23K 0K 0.0 /bin/inetd
79 S 67K 4K 0.0 /bin/syslogd -n
80 S 66K 4K 0.0 /bin/klogd -n
978 S 1686K 0K 24.9 /bin/mspscand
1192 S 0K 0K 0.0 lockd
1890 S 66K 4K 0.0 sleep 300
1891 S 26K 0K 0.0 /bin/telnetd
1892 p0 R 28K 4K 0.0 sh
Where mspscand is our main application. Notice how much CPU is being
consumed by kswapd. Previously (w/o page_alloc2() running) we did not see
this much time going to kswapd.
Is this normal behavior? And if so, how much CPU are we really sacrificing
to kswapd? If mspscand and kswapd have to compete for CPU, how do we give
priority to our application? Should we attempt to nice down kswapd? Are
there other tuning parameters we should be looking at?
We have noticed a significant slow down (2X) in a CPU and memory intensive
potion of
our application since page_alloc2() was deployed. But I have not yet run any
extensive
profiling to know exactly where the culprit is. I have been thinking of running
an
experiment w/o page_alloc2() configured to see if we really do gain the 2X back.
By carefully re-crafting the application to use static vs dynamic memory
allocation
and by using page_alloc2() all of our memory allocation errors and:
ksize on unknown page type (index=12)!
errors have gone away.
I'll be delving into the source code for page_alloc2() soon, but I was hoping
I could get a few pointers from the uClinux community first.
Thanks.
--
David Spain
SiCortex, Inc.
Three Clock Tower Place, Suite 210
Maynard, MA USA 01754 Email: [EMAIL PROTECTED]
_______________________________________________
uClinux-dev mailing list
[email protected]
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by [email protected]
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
