Linus Torvalds wrote:
>
> On Wed, 25 Oct 2000, Rik van Riel wrote:
> >
> > OTOH, block-dev readahead makes sense for filesystems where
> > the packing locality is close to the access pattern BUT NOT
> > close to anything the page cache would recognise as being
> > close.
>
> I dunno. The main re
On Thu, 26 Oct 2000, Linus Torvalds wrote:
> The alternative is to have an entirely different approach, where the page
> cache itself only knows about the maximum page (in which case your current
> "last_page" calculation is right on), and then anybody who needs to know
> about partial pages ne
"Jeff V. Merkey" wrote:
>
> Martin,
>
> A lot of changes. Have you tested this adequately? Changes of this
> magnitude this late in the 2.4 cycle could break a lot of stuff. I'll
> apply your patch, and let you know.
>
> :-)
>
> Jeff
Martin,
1. Adaptec SCSI driver on a 4 x P6 POCA blo
Martin,
A lot of changes. Have you tested this adequately? Changes of this
magnitude this late in the 2.4 cycle could break a lot of stuff. I'll
apply your patch, and let you know.
:-)
Jeff
Martin Dalecki wrote:
>
> Hello!
>
> Please have a look at the following patch and feel free to b
On Wed, 25 Oct 2000, Alexander Viro wrote:
>
> Linus, what do you think about that? I can do the remaining filesystems
> and give it initial testing today.
Ok, looks reasonable, if not really pretty. I'd probably prefer
last_page = size >> PAGE_CACHE_SIZE;
last_page_size = siz
Alexander Viro wrote:
>
> On Wed, 25 Oct 2000, Jeff V. Merkey wrote:
>
> > > > :%s/have/doesn't have/gc
> > >
> > > ??? Why the hell do you want a global replacement?
> >
> > not global replace, global CONFIRM. Just in case the
>
> Ugh. If you want to be pedantic that's G1:/have/s//doesn't
On Wed, 25 Oct 2000, Jeff V. Merkey wrote:
> > > :%s/have/doesn't have/gc
> >
> > ??? Why the hell do you want a global replacement?
>
> not global replace, global CONFIRM. Just in case the
Ugh. If you want to be pedantic that's G1:/have/s//doesn't &^M
for you.
-
To unsubscribe from this
Alexander Viro wrote:
>
> > > > > (e.g. generic_commit_write have to mess with i_size value to update the
> > > ^^^
> > > Ugh. s/have/doesn't have/, indeed. Sorry.
> >
> > Wrong syntax:
> >
> > :%s/have/doesn't have/gc
>
> ??? Why the hell do you want a glob
> On Wed, 25 Oct 2000, Jeff V. Merkey wrote:
>
> > Alexander Viro wrote:
> > >
> > > On Wed, 25 Oct 2000, Jeff V. Merkey wrote:
> > >
> > > > Al,
> > > >
> > > > Thanks. I'll print this one out and post it on the wall for tonight's
> > > > debugging session.
> > > [snip]
> > > > > (e.g. gener
On Wed, 25 Oct 2000, Jeff V. Merkey wrote:
> Alexander Viro wrote:
> >
> > On Wed, 25 Oct 2000, Jeff V. Merkey wrote:
> >
> > > Al,
> > >
> > > Thanks. I'll print this one out and post it on the wall for tonight's
> > > debugging session.
> > [snip]
> > > > (e.g. generic_commit_write have to
Erik Andersen wrote:
>
> On Wed Oct 25, 2000 at 02:15:05PM -0600, Jeff V. Merkey wrote:
> >
> >
> > Alexander Viro wrote:
> > >
> > > On Wed, 25 Oct 2000, Jeff V. Merkey wrote:
> > >
> > > > Al,
> > > >
> > > > Thanks. I'll print this one out and post it on the wall for tonight's
> > > > debug
On Wed Oct 25, 2000 at 02:15:05PM -0600, Jeff V. Merkey wrote:
>
>
> Alexander Viro wrote:
> >
> > On Wed, 25 Oct 2000, Jeff V. Merkey wrote:
> >
> > > Al,
> > >
> > > Thanks. I'll print this one out and post it on the wall for tonight's
> > > debugging session.
> > [snip]
> > > > (e.g. gener
Alexander Viro wrote:
>
> On Wed, 25 Oct 2000, Jeff V. Merkey wrote:
>
> > Al,
> >
> > Thanks. I'll print this one out and post it on the wall for tonight's
> > debugging session.
> [snip]
> > > (e.g. generic_commit_write have to mess with i_size value to update the
>
On Wed, 25 Oct 2000, Jeff V. Merkey wrote:
> Al,
>
> Thanks. I'll print this one out and post it on the wall for tonight's
> debugging session.
[snip]
> > (e.g. generic_commit_write have to mess with i_size value to update the
^^^
Ugh. s/have/doesn't have/, i
Rik van Riel wrote:
>
> On Wed, 25 Oct 2000, Jeff V. Merkey wrote:
> > Rik van Riel wrote:
> > > On Wed, 25 Oct 2000, Jeff V. Merkey wrote:
> > >
> > > > I've reviewed the patch. It's affect seems minimal and will not
> > > > break NWFS as proposed -- it looks like, however, it will reduce
> >
Al,
Thanks. I'll print this one out and post it on the wall for tonight's
debugging session.
:-)
Jeff
Alexander Viro wrote:
>
> On Wed, 25 Oct 2000, Alexander Viro wrote:
>
> > I can do the proof-of-concept patch (below 10Kb, ext2 + generic code, with
> > the need to repeat the fs-specific
On Wed, 25 Oct 2000, Jeff V. Merkey wrote:
> Rik van Riel wrote:
> > On Wed, 25 Oct 2000, Jeff V. Merkey wrote:
> >
> > > I've reviewed the patch. It's affect seems minimal and will not
> > > break NWFS as proposed -- it looks like, however, it will reduce
> > > the performance slightly of EXT2/
Rik van Riel wrote:
>
> On Wed, 25 Oct 2000, Jeff V. Merkey wrote:
>
> > I've reviewed the patch. It's affect seems minimal and will not
> > break NWFS as proposed -- it looks like, however, it will reduce
> > the performance slightly of EXT2/3 with iozone for read ahead
> > since the first s
On Wed, 25 Oct 2000, Alexander Viro wrote:
> I can do the proof-of-concept patch (below 10Kb, ext2 + generic code, with
> the need to repeat the fs-specific parts for other filesystems) in an
> hour. Clearance?
OK, it didn't take an hour. Warning: completely untested, needs
(trivial) changes t
On Wed, 25 Oct 2000, Jeff V. Merkey wrote:
> I've reviewed the patch. It's affect seems minimal and will not
> break NWFS as proposed -- it looks like, however, it will reduce
> the performance slightly of EXT2/3 with iozone for read ahead
> since the first section of the patch limits the read a
Rik,
I've reviewed the patch. It's affect seems minimal and will not break
NWFS as proposed -- it looks like, however, it will reduce the
performance slightly of EXT2/3 with iozone for read ahead since the
first section of the patch limits the read ahead window size. NWFS uses
it's own read ah
Where's the patch located? It's not attached to this email.
Jeff
Rik van Riel wrote:
>
> On Wed, 25 Oct 2000, Alexander Viro wrote:
> > On Wed, 25 Oct 2000, Rik van Riel wrote:
> >
> > > Anyway, below is a patch that implements Al Viro's
> > > readahead fix and one small readahead adjustment
Alexander Viro wrote:
>
> On Wed, 25 Oct 2000, Linus Torvalds wrote:
>
> >
> >
> > On Wed, 25 Oct 2000, Rik van Riel wrote:
> > >
> > > OTOH, block-dev readahead makes sense for filesystems where
> > > the packing locality is close to the access pattern BUT NOT
> > > close to anything the page
On Wed, 25 Oct 2000, Alexander Viro wrote:
> On Wed, 25 Oct 2000, Rik van Riel wrote:
>
> > Anyway, below is a patch that implements Al Viro's
> > readahead fix and one small readahead adjustment
> > that seems to make sense ...
>
> Rik, doesn't said fix need propagation into your adjustment?
Y
On Wed, 25 Oct 2000, Rik van Riel wrote:
> Anyway, below is a patch that implements Al Viro's
> readahead fix and one small readahead adjustment
> that seems to make sense ...
Rik, doesn't said fix need propagation into your adjustment?
-
To unsubscribe from this list: send the line "unsubscr
On Wed, 25 Oct 2000, Linus Torvalds wrote:
>
>
> On Wed, 25 Oct 2000, Rik van Riel wrote:
> >
> > OTOH, block-dev readahead makes sense for filesystems where
> > the packing locality is close to the access pattern BUT NOT
> > close to anything the page cache would recognise as being
> > clos
On Wed, 25 Oct 2000, Linus Torvalds wrote:
> On Wed, 25 Oct 2000, Rik van Riel wrote:
> >
> > OTOH, block-dev readahead makes sense for filesystems where
> > the packing locality is close to the access pattern BUT NOT
> > close to anything the page cache would recognise as being
> > close.
>
> I
On Wed, 25 Oct 2000, Rik van Riel wrote:
>
> OTOH, block-dev readahead makes sense for filesystems where
> the packing locality is close to the access pattern BUT NOT
> close to anything the page cache would recognise as being
> close.
I dunno. The main reason I'd like to get the block devices
On Tue, 24 Oct 2000, Linus Torvalds wrote:
> On Tue, 24 Oct 2000, Jeff Garzik wrote:
> >
> > I agree with you and Rik that this array needs to go away... but
> > ripping out the feature is not the answer, IMHO.
>
> Actually, the _real_ answer is to make fs/block_dev.c use the
> page cache inste
On Wed, Oct 25, 2000 at 12:30:49AM +0200, Ingo Oeser wrote:
> On Tue, Oct 24, 2000 at 12:46:36PM -0700, Linus Torvalds wrote:
> > Actually, the _real_ answer is to make fs/block_dev.c use the page cache
> > instead - and generic_file_read() does read-ahead that actually improves
> > performance, u
On Tue, Oct 24, 2000 at 12:46:36PM -0700, Linus Torvalds wrote:
> Actually, the _real_ answer is to make fs/block_dev.c use the page cache
> instead - and generic_file_read() does read-ahead that actually improves
> performance, unlike the silly contortions that the direct block-dev
> read-ahead t
Jeff Garzik wrote:
>
> > Please have a look at the following patch and feel free to be scared
> > by the fact how UTTERLY BROKEN and ARBITRARY the current usage of the
> > read_ahead[] array and during the whole past decade was!
> > If you really care about clean internal interfaces this should b
On Tue, 24 Oct 2000, Jeff Garzik wrote:
>
> I agree with you and Rik that this array needs to go away... but
> ripping out the feature is not the answer, IMHO.
Actually, the _real_ answer is to make fs/block_dev.c use the page cache
instead - and generic_file_read() does read-ahead that actua
> Please have a look at the following patch and feel free to be scared
> by the fact how UTTERLY BROKEN and ARBITRARY the current usage of the
> read_ahead[] array and during the whole past decade was!
> If you really care about clean internal interfaces this should be
> one of those prio number O
Rik van Riel wrote:
>
> On Tue, 24 Oct 2000, Martin Dalecki wrote:
>
> > The most amanzing thing is that the whole test10-pre5 kernel
> > with this patch applied doesn't show any performance penalties
> > for me at all! And of corse it's about 10k smaller...
>
> Ideally we should (IMHO) get rid
On Tue, 24 Oct 2000, Martin Dalecki wrote:
> The most amanzing thing is that the whole test10-pre5 kernel
> with this patch applied doesn't show any performance penalties
> for me at all! And of corse it's about 10k smaller...
Ideally we should (IMHO) get rid of all MAX_BLKDEV arrays.
They take
Hello!
Please have a look at the following patch and feel free to be scared
by the fact how UTTERLY BROKEN and ARBITRARY the current usage of the
read_ahead[] array and during the whole past decade was!
If you really care about clean internal interfaces this should be
one of those prio number ONE
37 matches
Mail list logo
