>
> On Wed, 1 Dec 1999, Alexander Viro wrote:
>
> > > looks good, but i think you have removed an important optimization:
> > > overlapping the issuing/finishing of read requests with copying memory, on
> > > 1k filesystems. This should not matter much on bigger boxes, but on
> > > smaller ones i've seen a definite advantage. So it's fine (and wanted) to
> >
> > Erm... I'm not sure that it's going to be a win - could you describe a
> > scenario where we would write enough to make the copying sufficiently long
> > _and_ would hit the need to wait on read request at the last block? IOW,
>
> i saw this with PIO EIDE, but it's a generic rule that we want to delay
> waiting for anything as much as possible - if it's easy. And in this case
> it's not hard. The rule: delay blocking as much as possible, start device
> requests as early as possible.
Unfortunately, it becomes _really_ messy if we want to zero some part out
(normal for continuous-only filesystem). I'll look at it more, but I have
a nasty feeling that we may lose more on extra code.
> > what situation did you catch when testing old code? It _did_ wait on the
> > first read request before copying anything, so if there was a difference
> > it either came from waiting on the last one or from something completely
> > different.
>
> it has to wait for every request it's going to copy, obviously - but it
> only waited for it once it was absolutely necessery. Nevertheless the old
> code had other problems (it didnt start the reads in advance, which your
> version does) - but i believe it's still not 'perfect'. You asked for
> comments! :-)
And am grateful for getting them ;-)
> > > issue read requests first (the old version didnt do this), but you are
> > > waiting for them to finish synchronously - this should be interleaved with
> > > memory copies. Also there is a deadlock situation which David Miller
> > > noticed some time ago (i think this is still present): just try read()-ing
>
> [wrong description, try write()-ing.]
Oh, fsck... It's even more interesting for mutual deadlocks. And then
there is a wonderful situation with writing into mmaped area with offset 1
byte... Hrrrrrmmm... I wonder how well other kernels handle that. The most
obvious way would be to force page-in before grabbing the destination page
and to get_page() on (one or two) pages containing the source. Messy.
-
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/