Hi,
Andrew Morton wrote:
I suspect I was fooled by the oprofile output, which showed tremendous
amounts of load in schedule() and switch_to(). The percentages which
opreport shows are the percentage of non-halted CPU time. So if you have a
function in the kernel which is using 1% of the total CPU, and the CPU is
halted for 95% of the time, it appears that the function is taking 20% of
CPU!
The fix for that is to boot with the "idle=poll" boot parameter, to make
the CPU spin when it has nothing else to do.
I'll test again the two_discs_bad situation after booting with that
parameter. Thanks.
I'm suspecting that your machine is just stuck in D state waiting for disk.
Did we have a sysrq-T trace?
The amazing thing is that this doesn't happen! Every single cron jobs
that keeps running (I intentionally said that before too) and never
ends is in R state. By strace'ing the processes they just seem to be
going *extremely* slow. I also changed the I/O elevator of hdb (the OS
disk) to deadline from cfq, unfortunately with no results. That is why I
've been considering it a CPU scheduler issue.
Dimitris
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
