[lkml]   [2001]   [Nov]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 2.4.14-pre6
Neil Brown wrote:
> ...
> What I would like is that as soon as a buffer was marked "dirty", it
> would get passed down to the driver (or at least to the
> block-device-layer) with something like
> submit_bh(WRITEA, bh);
> i.e. a write ahead. (or is it write-behind...)
> The device handler (the elevator algorithm for normal disks, other
> code for other devices) could keep them ordered in whatever way it
> chooses, and feed them into the queues at some appropriate time.

Sounds sensible to me.

In many ways, it's similar to the current scheme when it's used
with an enormous request queue - all writeable blocks in the
system are candidates for request merging. But your proposal
is a whole lot smarter.

In particular, the current kupdate scheme of writing the
dirty block list out in six chunks, five seconds apart
does potentially miss out on a very large number of merging
opportunities. Your proposal would fix that.

Another potential microoptimisation would be to write out
clean blocks if that helps merging. So if we see a write
for blocks 1,2,3,5,6,7 and block 4 is known to be in memory,
then write it out too. I suspect this would be a win for
ATA but a loss for SCSI. Not sure.

But I have a gut feel that all this is in the noisefloor,
compared to The Big Problem. It's just a matter of identifying
and fixing TBP. Fixing the fdatasync() thing didn't help,
because ext2_write_inode() for a new file has to read the
inode block from disk. Fixing that, by doing an async preread
of the inode's block in ext2_new_inode() didn't help either,
I suspect because my working set was so large that the VM
tossed out my preread before I got to use it. A few more days
poking is needed.

Oh. I have a gripe concerning prune_icache(). The design
idea behind keventd is that it's a "process context bottom
half handler". It's used for things like cardbus hotplug
interrupt handlers, handling tty hangups, etc. It should
probably run SCHED_FIFO.

Using keventd to synchronously flush large amounts of
data out to disk constitutes gross abuse - it's being blocked
from performing its designed duties for many seconds. Can we
please not do that? We already have kswapd, kupdate, bdflush,
which should be sufficient.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:12    [W:0.086 / U:5.000 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site