Messages in this thread | | | Date | Tue, 05 Mar 2002 15:24:49 -0800 | From | Andrew Morton <> | Subject | Re: 2.4.19pre1aa1 |
| |
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).
- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |