Sorry, I was unclear - it's only 100% busy during those 45s.
This is what it looks like if I first start the load monitor (-r outputs
1 sample/second), then start to log in from a remote ssh client:
# cpu -r
CPU: busy 0% (system=0% user=0% nice=0% idle=100%)
CPU: busy 24% (system=4% user=19% nice=0% idle=75%)
CPU: busy 100% (system=1% user=98% nice=0% idle=0%)
CPU: busy 100% (system=0% user=100% nice=0% idle=0%)
<39 repeats of the above busy 100%>
CPU: busy 100% (system=2% user=97% nice=0% idle=0%)
CPU: busy 100% (system=8% user=91% nice=0% idle=0%)
CPU: busy 100% (system=22% user=77% nice=0% idle=0%)
CPU: busy 100% (system=0% user=100% nice=0% idle=0%)
CPU: busy 100% (system=0% user=100% nice=0% idle=0%)
CPU: busy 67% (system=8% user=58% nice=0% idle=32%)
CPU: busy 0% (system=0% user=0% nice=0% idle=100%)
Thanks for the tip on prebuilt busybox Rob, but would I need it in flat
format. I don't think arm-elf-elf2flt can do that without reloc info or?
And from the above I don't think it would add much info.
My question is:
Is 45s reasonable on a 192MHz cpu, or do you think I might have some
issue with my compilation options (see my first post,
http://hi.baidu.com/kkernel/blog/item/ff919681141beddebc3e1e23.html but
with --disable-shadow) or something?
Anyone who has similar experiences? Or the opposite, someone who's
running it on a low-end system without this issue?
My next step is probably to trace and see where it's spending the time.
Kind regards/Magnus
On 2011-03-14 22:53, Rob Landley wrote:
On 03/14/2011 10:09 AM, Magnus Nilsson wrote:
Both top and ps are the gimped uClinux versions, but I found the cpu tool:
# cpu -r
CPU: busy 100% (system=0% user=99% nice=0% idle=0%)
CPU: busy 100% (system=0% user=100% nice=0% idle=0%)
...
So indeed it looks busy. Any suggestions what I can do to lighten the load?
What's using the load?
Does the http://busybox.net/downloads/binaries/latest/busybox-armv4tl
binary work for you? (or the armv4l one if you're using oabi?)
That should let you run "top"...
Rob
