The New Linux Speed Trick

Brainsur quotes a story saying " Linux kernel 2.6 introduces improved IO scheduling that can increase speed -- "sometimes by 1,000 percent or more, [more] often by 2x" -- for standard desktop workloads, and by as much as 15 percent on many database workloads, according to Andrew Morton of Open Source Development Labs. This increased speed is accomplished by minimizing the disk head movement during concurrent reads. "

Comments

Re:1,000 percent?

[gowen]

My guess is that it's a fairly specific, non-standard load that will garner a 1000x gain

My guess is that you haven't spotted that 1,000% is not 1,000x. A 10-fold increase isn't completely implausible for a workload whose read pattern matches the assumptions built into the anticipatory scheduler.

Re:Why not combine those two methods?

[Anonymous Coward]

I believe that the anticipatory sched uses the model of the deadline sched. See "Linux Kernel Development" by Robert Love.

Re:1,000 percent?

[tonywestonuk]

Isn't 1000%, 11x?
15% = 1.15x
100% = 2x
200% = 3x
300% = 4x ..
900% = 10x
1000% = 11x

a % = (a+100)/100 x

Benchmark

[zz99]

Here's an older benchmark made by Andrew Morton showing the anticipatory scheduler vs the previous one.

The benchmark was made before 2.6.0, but I still think it shows the big difference from the 2.4 IO scheduler.

Quote:
Executive summary: the anticipatory scheduler is wiping the others off the map, and 2.4 is a disaster.

Re:SCSI

[DuSTman31]

Yeah, I think so. IIRC it's called tagged command queueing - the drive can have multiple requests pending and instead of doing them first come first served, they're fulfilled in order of estimated latency to that point.

I believe Western Digital's recent Raptor IDE drives have the same feature.

The benefit of this seems contingent upon having multiple requests pending, which AFAIK is hard on linux as there's no non-blocking file IO. To me, this reads like a workaround for that.

You're misunderstanding something...

[warrax_666]

AFAIK the "anticipation" bit is not so much about predicting head movement, but is more about reducing head movement. Reads
cause processes to block while waiting for the data (and can thus stall processes for long amounts of time if not scheduled appropriately), whereas writes are typically fire-and-forget. This last bit means that you can usually just queue them up, return control to the user program, and perform the actual write at some more convenient time, i.e. later. Since reads (by the same process) are usually also heavily interdependent, it is also a win to schedule them early from that POV.

That's my understanding of it.

Re:Cache?

[Erik Hensema]

Sure, and both Linux 2.4 and 2.6 do caching and read-ahead (reading more data than requested, hoping that the application will request the data in the future).

The I/O scheduler however lies beneath the cache layer. When it's decided that data must be read from or written to disk, the request is placed in a queue. The scheduler may reorder the queue in order to minimize head movements.

Also, 2.6 has the anticipatory I/O scheduler: after a read, the scheduler simply pauses for a (very) short period. This is done in the assumption that the application will request more data from the same general area on the disk. Even when other requests are in the I/O queue, requests to the area where the disk's heads are hovering will get priority.

While this increases latency (the time it takes for a request to be processed) a bit, throughput (the amount of data transfered in a time period) will also increase.

It did take a fair amount of experimenting and tuning in order to make the I/O scheduler work as well as it does now. However there still may be some corner cases where the new scheduler is much slower than the old.

Re:I've found the opposite

[bflong]

Make sure that you set X's "nice" value to 0. Some distros set it to something like -10 so that X is not disturbed by other procs. Under 2.4, this was a good thing. However, under 2.6, with it's superior scheduler, the kernel will keep interrupting X and you will see lagging performance. Google for it to get a better explanation.

Re:what's old is new again

[Yokaze]

Elevator seeking is looking at the current request queue and bundle requests which are close together to minimise head movement. This is indeed old. IRC, Linux had it since 2.2 something.

The anticipatory scheduler tries to anticipate future requests (who would have guessed that?), and is relatively new