Messages in this thread | | | Date | Wed, 31 Oct 2001 11:06:32 -0800 (PST) | From | Linus Torvalds <> | Subject | Re: 2.4.14-pre6 |
| |
On Wed, 31 Oct 2001, Andrew Morton wrote: > > But it's actually quite seductive to take a huge amount of data and > just chuck it at the request layer and let Jens sort it out. This > usually works well and keeps the complexity in one place.
Fair enough, I see your point. How would you suggest we handle the latency thing, though?
I'm not against making the elevator more intelligent, and you have a good argument. But I've very much against "allow the queues to grow with no sense of latency".
> One does wonder whether everything is working as it should, though. > Creating those 100,000 4k files is going to require writeout of > how many blocks? 120,000? And four minutes is enough time for > 34,000 seven-millisecond seeks. And ext2 is pretty good at laying > things out contiguously. These numbers don't gel. > > Ah-ha. Look at the sync_inodes stuff: > > for (zillions of files) { > filemap_fdatasync(file) > filemap_fdatawait(file) > } > > If we turn this into > > for (zillions of files) > filemap_fdatasync(file) > for (zillions of files) > filemap_fdatawait(file)
Good catch, I bet you're right.
> kupdate runs this code path as well. Why is there any need for > kupdate to wait on the writes?
At least historically (and I think it's still true in some cases), kupdated was also in charge of trying to write out buffers under low-memory circumstances. And without any throttling, blind writing can make things worse.
However, the request throttle should be _plenty_ good enough, so I think you're right.
Oh, one issue in case you're going to work on this: kupdated does need to do the "wait_for_locked_buffers()" at some point, as that is also what moves buffers from the locked list to the clean list. But that has nothing to do with the fdatawait thing.
Linus
- 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/
| |