Salix Forums

This is strange, and probably not too relevant for most desktop users. Nonetheless...

I've noticed that, if you create a large empty file, e.g. while using the noop I/O scheduler, the mouse cursor will freeze for long periods of time, and sometimes the kernel will crash (i.e. cursor never unfreezes, sysrq keys won't work).

So of course I looked at CPU use while doing this... And guess what, it produces regular spikes of ~100% CPU use, coinciding with the freezes. The cfq scheduler by contrast never produces CPU use higher than about 80%.

You can probably see the issue here. noop is the simplest scheduler, designed to incur the lowest CPU use, at the cost of potentially higher latency and lower throughput. I'm not a kernel hacker, but I'm pretty sure that per its design it should never generate CPU spikes like that. Yet this happens on the 2.6.37.6 kernel, and every other kernel I've tried.

Is this a bug, or am I missing something essential?

GJones wrote:noop is the simplest scheduler, designed to incur the lowest CPU use, at the cost of potentially higher latency and lower throughput.

It's right that noop is meant to be simple. But that doesn't mean it creates the lowest cpu load. Actually just the scheduling overhead is lowered that way i.e. the cpu usage created by deciding what to do next. That doesn't mean that the cpu load caused otherwise is decreased or that the total cpu load related to io is lowered.

Generally speaking: simple scheduler --> low scheduler overhead, bad performance/decisions otherwise --> only better on low resource systems where the additional scheduling overhead DOES matter and the bad decisions do NOT have a big enough impact due to few jobs for example
Otherwise you're using a scheduler unsuited for your use case. As the scheduling overhead doesn't matter on normal systems but the bad decisions do a lot, such a scheduler can only give you bad performance.

Imagine you had to create a timetable. Now you spend few time on that and just put the stuff somewhere where it fits like noop without wasting any brain power. You probably would get many gaps, would have to travel a lot, ... which in the end gives you a much worse time usage although you initially spent less time on creating the timetable. On the other hand there might be also timetables where it doesn't matter and which wouldn't become that bad. Then of course initially spending less time would be beneficial.

Finally be careful when playing with schedulers especially once for special use cases and bad scalability. If you don't have a fair understanding there, you hardly will be able to optimize anything compared to a balanced (i.e. not always optimal), scalable default.

Thank you, that explained rather a lot.

It seems rather interesting though that the kernel is crashing/hard freezing. Not sure whether that's completely intentional and expected behaviour (under such use).

GJones wrote:

Code: Select all

dd if=/dev/zero of=dumpfile bs=4K count=1M

while using the noop I/O scheduler, the mouse cursor will freeze for long periods of time

dd generates a hell of a lot IO requests here and with the noop scheduler there is no balancing done: first request is served first, that's why everything else get's slow.

and sometimes the kernel will crash (i.e. cursor never unfreezes, sysrq keys won't work).

The kernel should not crash. That never happens Can you still ping the machine? Do you have sysreq keays anabled in your kernel config (AFAIK they are disabled in default kernel).

Ooh... Might be that the keys are disabled by default. I was pretty sure Slackware and derived distros enabled magic sysrq by default, but I could be wrong.

Haven't tried pinging the "crashed" machine, I'll see about that at some point...

GJones wrote:I was pretty sure Slackware and derived distros enabled magic sysrq by default

You are right: But still you have the IO problem, which I guess could make keyboard input for magic sysreq impossible.

The kernel have it, but the magic keys are disabled in Xorg if I remember correctly.

Just an update: I tried this again on Fedora 16... this behavior is a bug. Not only do crashes never occur with the noop scheduler on Fedora, CPU usage never goes above 20% while running dd.

(As for desktop performance, IO bandwidth does get hogged and programs do take longer to start up under load. But OTOH, already running programs remain more responsive under load. Whether this is a reasonable compromise for a desktop, I'll have to see.)

You could try the more recent kernel I posted in the contributed packages section.