Messages in this thread | | | Date | Tue, 05 Mar 2002 15:51:37 -0800 | From | Andrew Morton <> | Subject | Re: 2.4.19pre1aa1 |
| |
Andrea Arcangeli wrote: > > > depends what you're doing, if you do `cp /dev/zero .` and the fs is > lucky enough to have free contigous space I definitely can see the > improvement of highlevel merging, but that's not always what you're > doing with the fs, for example that's not the case for kernel compiles > and small files where you'll be always fragmented and where the bio will > at max hold 4k and you keep rewriting into cache.
Cache effects. We touch the buffers at prepare_write. We touch them again at commit_write(). And at writeout time. And at page reclaim time. I think it's this general white-noise cost which is causing the funny profiles which I'm seeing. (For example, with no-buffers, the cost of the IDE driver setup and interrupt handler has nosedived).
> The times you enter > get_block you enter in a fs lock, rather than staying at the per-page > lock, it's not additional locking, the bh on the pagecahce doesn't need > any additional locking.
For writes, we have the lru list insertion, and the hashtable lock (twice).
> So for a kernel compile the current situation is > an obvious advantage in performance and scalability (fs code definitely > doesn't scale at the moment).
mm.. Delayed allocation means that the short-lived files never get a disk mapping at all.
And yes, if all files are 100% fragmented then the BIO aggregation doesn't help as much.
> But ok, globally it will be probably better to drop the bh since we have > to work on the bio anyways somehow and so at the very least we don't > want to be slowed down from the bio logic in the physically contigous > pagecache flood case. > > I just meant the bh isn't totally pointless and it could be shrunk as > Arjan said in a private email.
bh represents a disk block. It's a wrapper around a section of the block device's pagecache pages. We'll always need a representation of disk blocks. For filesystem metadata.
- - 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/
| |