[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [microblaze-uclinux] Minux shell
Hi Bret,
Bret Ketchum wrote:
Before I start digging around for an answer, I'm wondering if
anybody can explain why
invoking the Minux shell:
# /bin/msh -c ls
Chews up roughly 98 percent of the available MIPs and the bulk of
those MIPs are
used in the kernel? Does that seem reasonable?
I might be missing something, but if ls is the only process that's doing
any work on the CPU, then yes it seems reasonable. If there's no
competition for the CPU, then the only runnable process should get
nearly 100%. And, since ls is primarily a wrapper around a system call,
and some pretty formatting of the results, I am not surprised that most
of the time would be spent in the kernel.
If, however, there is some other process(es) running, then it would seem
a little odd that ls should dominate, unless you've nice'd those other
processes or are in some way playing with the scheduler and priorities.
# vmstat -n 1
procs memory swap io system
cpu
r b w swpd free buff cache si so bi bo in cs us sy
id
4294967295 0 2 0 47768 0 1620 0 0 1 0 120 362
0 13 87
4294967295 0 1 0 47768 0 1620 0 0 0 0 134 469
6 7 87
4294967295 0 1 0 47768 0 1620 0 0 0 0 137 467
9 4 86
4294967295 0 1 0 47768 0 1620 0 0 0 0 141 475
7 6 87
4294967295 0 1 0 47768 0 1620 0 0 0 0 134 460
7 5 88
4294967295 0 1 0 47768 0 1620 0 0 0 0 135 464
9 4 87
4294967295 0 1 0 47768 0 1620 0 0 0 0 134 460
7 6 87
4294967295 0 2 0 47528 0 1712 0 0 52 0 146 463
11 19 70
4294967295 0 4 0 47292 0 1712 0 0 0 0 201 199
12 86 2
4294967295 0 2 0 47292 0 1712 0 0 0 0 141 461
7 7 86
The wrap makes this hard to read, but I am guessing that the "spike" you
mention is towards the end there, where the system load goes up to 86%
and the userspace load to 12% (86+12 = 98)? As I said, if there's
nothing else happening, the scheduler will throw all of the CPU at ls.
Something to try - build the "dhrystone" app, and launch multiple copies
of it at once, all doing a very large number of iterations so it won't
terminate during your test. It's an easy way to create purely CPU bound
load, since it does no IO at all.
It's not a very useful benchmark, but it is a good way to load up the
CPU and give the scheduler something to think about.
Repeat your test, and see what happens.
I'd be a bit suspicious of the "r" (runnable) column there - it looks
like -1 (or 0xffffffff) displayed as an unsigned int. Why is that?
I can't say I've ever had call to use vmstat on a nommu machine -
definitely worth googling the uclinux-dev archives to see if there are
any nonmmu-isms that affect its operation. It seems a pretty likely
candidate, for obvious reasons.
A little background may be useful; the Microblaze is running at 78
MHz, we have 64MB of SDRAM and /var/log is mount on 64MB of NOR flash. Any
hints will be appreciated.....
Nothing stands out there - unless the "ls" is recursing over the flash
mount which case you expect see some extra system and IO load if the
buffer cache is cold.
I assume you've got at least minimal data and instruction caches?
Cheers,
John
___________________________
microblaze-uclinux mailing list
microblaze-uclinux@xxxxxxxxxxxxxx
Project Home Page : http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux
Mailing List Archive : http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/