lkml.org 
[lkml]   [1999]   [Dec]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [CFT][PATCH] block_write_*_buffer rewrite

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.

> 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! :-)

> > 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.]

> > a file into a freshly mmap()-ed memory area. (where the mmap-ed page is
> > the same as the read() page.) Legal combination, instant stuck process.
>
> Huh? generic_file_read() unlocks the page before calling actor() (and
> causing the page-in). What's the problem with it?

the problem is generic_file_write() locking the page while generating a
page fault (to the same page).

-- mingo


-
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/

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