> Hi,
>
> On Sun, 15 Nov 1998 20:38:05 +0100 (MET), Gerard Roudier
> <groudier@club-internet.fr> said:
>
> > My understanding of Linux architecture is that IO blocks coalescing only
> > occurs in ll_rw_blk.c.
>
> Yes, except for scsi which does its Own Thing, of course.
Once the device queue depth is full, other requests stay in the ll_rw_blk
request list and are handled the same way as IDE requests with regards to
coalescing and sorting, unless I missed something important.
> > If it fails the coalescing then Linux will just do 1 IO for each
> > block. When you have lots of memory, it may happen the number of
> > entries in the request array (NR_REQUEST) be not enough for this
> > coalescing to occur in some situations that may not be rare given the
> > way the buffer cache actually work.
>
> The way it actually works, sequential writes tend to be kept in
> sequential order in the buffer cache lists, so the typical cases work
> pretty well. All the benchmarks show that sequential filesystem writes
> work very well.
Yes, it works for sequential writes, at least when you aren't doing too
much concurrent sequential writes as the same time. It seem not to work
that well for the inode table when you traverse a large number of inodes
(mounted rw with atime updates). BTW, 'find / -name sdfgsdgsd' is a nice
way to stress the SCSI IO subsystem, especially for tagged queueing ->
bunches of 1 block IO requests pushed into the SCSI subsystem.
When I imagine a system with a large memory space, for example 1 GB,
running several hundreds of processes (thousands?) performing writes, all
of them sharing the only 64 requests (NR_REQUEST) in 2.1.128 kernel, I
cannot believe that coalescence will work that well.
Did I miss something important?
Regards,
Gerard.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/