Re: 2.4.19pre1aa1

[Andrew Morton <akpm@zip.com.au>]

Andrea Arcangeli wrote:
> 
> BTW, I noticed one of my last my email was a private reply so I'll
> answer here too for the buffer_head pagecache I/O part:

Heh.  Me too.
 
> Having persistence on the physical I/O information is a good thing, so
> you don't need to resolve logical to physical block at every I/O and bio
> has a cost to setup too. The information we carry on the bh isn't
> superflous, it's needed for the I/O so even if you don't use the
> buffer_head you will still need some other memory to hold such
> information, or alternatively you need to call get_block (and serialize
> in the fs) at every I/O even if you've plenty of ram free. So I don't
> think the current setup is that stupid, current bh only sucks for the
> rawio and that's fixed by bio.

The small benefit of caching the get_block result in the buffers
just isn't worth it.

At present, a one-megabyte write to disk requires the allocation
and freeing and manipulation and locking of 256 buffer_heads and
256 BIOs.  lru_list_lock, hash_table_lock, icache/dcache
thrashing, etc, etc.   It's an *enormous* amount of work.

I'm doing the same amount of work with as few as two (yes, 2) BIOs.

This is not something theoretical.  I have numbers, and code.
20% speedup on a 2-way with a workload which is dominated
by copy_*_user.  It'll be more significant on larger machines,
on machines with higher core/main memory speed ratios, on
machines with higher I/O bandwidth. (OK, that bit was theoretical).

-