> The Statement relates to increased parallelism on FS code paths
> (they don't have to block), and allows multiple I/O requests to be
> handled as a "bundle" rather than one at a time. The benefit is
> immediately obvious since less time is spent calling semaphore and
> sync code in the kernel (shorter code paths, less rendudant
You seem to make a somewhat outdated optimisation here, offering
up I/O bandwidth (disk time) to save on CPU time. With the way
the processor/memory/disk speed 'balance' is going, I don't know
if that would be a tenable situation in the future.
The "I'm idle now, gimme work" idea is a very sane idea when
processors and memory are outrunning disk speed by many orders
of magnitude (and the gap is widening on a monthly basis).
Of course, it doesn't make much sense to give a disk it's block
when we've only got one page ready to write out, but once we
have 64 or 128 kB, it all starts to make sense.
regards,
Rik -- There's no seek time like idle time
-- The Internet is not a network of computers. It is a network of people. That is its real strength.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/