On Friday, January 05, 2001 04:32:50 PM -0200 Marcelo Tosatti
<[EMAIL PROTECTED]> wrote:
>> > I think we want to remove flush_dirty_buffers() from bdflush.
>> >
>>
>> Whoops. If bdflush doesn't balance the dirty list, who does?
>
> Who marks buffers dirty.
>
> Linus changed mark_buffer_
On Fri, 5 Jan 2001, Marcelo Tosatti wrote:
> On Fri, 5 Jan 2001, Rik van Riel wrote:
>
> > Also, you do not want the writer to block on writing out buffers
> > if bdflush could write them out asynchronously while the dirty
> > buffer producer can work on in the background.
>
> flush_dirty_buffer
On Fri, 5 Jan 2001, Rik van Riel wrote:
> Also, you do not want the writer to block on writing out buffers
> if bdflush could write them out asynchronously while the dirty
> buffer producer can work on in the background.
flush_dirty_buffers() do not wait on the buffers written to get clean.
On Fri, 5 Jan 2001, Marcelo Tosatti wrote:
> On Fri, 5 Jan 2001, Chris Mason wrote:
> > On Friday, January 05, 2001 01:43:07 PM -0200 Marcelo Tosatti
> > <[EMAIL PROTECTED]> wrote:
> > > On Fri, 5 Jan 2001, Chris Mason wrote:
> > >
> > >>
> > >> Here's the latest version of the patch, against 2.
On Fri, 5 Jan 2001, Chris Mason wrote:
>
>
> On Friday, January 05, 2001 01:43:07 PM -0200 Marcelo Tosatti
> <[EMAIL PROTECTED]> wrote:
>
> >
> > On Fri, 5 Jan 2001, Chris Mason wrote:
> >
> >>
> >> Here's the latest version of the patch, against 2.4.0. The
> >> biggest open issues are wh
On Friday, January 05, 2001 01:43:07 PM -0200 Marcelo Tosatti
<[EMAIL PROTECTED]> wrote:
>
> On Fri, 5 Jan 2001, Chris Mason wrote:
>
>>
>> Here's the latest version of the patch, against 2.4.0. The
>> biggest open issues are what to do with bdflush, since
>> page_launder could do everythin
Hi Chris,
I don't know if this is already known,
but this patch seems to solve the loop block device problem too.
I've tested it several times and did not get any kernel lockups after
applying the patch.
Until now this was a showstopper for me but you gave the solution.
Thank you very much.
Juer
Marcelo Tosatti wrote:
>
> On Fri, 5 Jan 2001, Chris Mason wrote:
>
> >
> > Here's the latest version of the patch, against 2.4.0. The
> > biggest open issues are what to do with bdflush, since
> > page_launder could do everything bdflush does.
>
> I think we want to remove flush_dirty_buffers
On Friday, January 05, 2001 01:43:07 PM -0200 Marcelo Tosatti
<[EMAIL PROTECTED]> wrote:
>
> On Fri, 5 Jan 2001, Chris Mason wrote:
>
>>
>> Here's the latest version of the patch, against 2.4.0. The
>> biggest open issues are what to do with bdflush, since
>> page_launder could do everythin
On Fri, 5 Jan 2001, Chris Mason wrote:
>
> Here's the latest version of the patch, against 2.4.0. The
> biggest open issues are what to do with bdflush, since
> page_launder could do everything bdflush does.
I think we want to remove flush_dirty_buffers() from bdflush.
While we are trying
Here's the latest version of the patch, against 2.4.0. The
biggest open issues are what to do with bdflush, since
page_launder could do everything bdflush does. And, how to
deal with writepage funcs that return 1 for fsync_inode_buffers.
-chris
diff -urN linux.2.4.0/fs/buffer.c linux/fs/buffe
On Friday, December 29, 2000 06:58:01 PM +0100 Daniel Phillips
<[EMAIL PROTECTED]> wrote:
> Chris Mason wrote:
>>
>> BTW, the last anon space mapping patch I sent also works on test13-pre5.
>> The block_truncate_page fix does help my patch, since I have bdflush
>> locking pages ( thanks Marcel
On Fri, 29 Dec 2000, Marcelo Tosatti wrote:
> Now the ext2 changes will for sure make a difference since right now the
> superblock lock is suffering from contention.
superblock lock is suffering from more than just contention. Consider the
following:
sys_ustat() does get_super(), which leav
On Fri, 29 Dec 2000, Chris Mason wrote:
> BTW, the last anon space mapping patch I sent also works on test13-pre5.
> The block_truncate_page fix does help my patch, since I have bdflush
> locking pages ( thanks Marcelo )
Good to know. I thought that fix would not change performance noticeable.
Chris Mason wrote:
>
> On Thursday, December 28, 2000 11:29:01 AM -0800 Linus Torvalds
> <[EMAIL PROTECTED]> wrote:
> [ skipping io on the first walk in page_launder ]
> >
> > There are some arguments for starting the writeout early, but there are
> > tons of arguments against it too (the main on
On Thursday, December 28, 2000 11:29:01 AM -0800 Linus Torvalds
<[EMAIL PROTECTED]> wrote:
[ skipping io on the first walk in page_launder ]
>
> There are some arguments for starting the writeout early, but there are
> tons of arguments against it too (the main one being "avoid doing IO if
> yo
On Thu, 28 Dec 2000, Chris Mason wrote:
>
> Linus and Rik are cc'd in to find out if this is a good idea in
> general.
Probably.
There are some arguments for starting the writeout early, but there are
tons of arguments against it too (the main one being "avoid doing IO if
you can do so"), so
On Thursday, December 28, 2000 16:49:14 +0100 Daniel Phillips <[EMAIL PROTECTED]>
wrote:
[ dbench 48 test on the anon space mapping patch ]
>
> This benchmark doesn't seem to suffer a lot from noise, so the 7%
> slowdown with your patch likely real.
>
Ok, page_launder is supposed to run th
Chris Mason wrote:
>
> On Wednesday, December 27, 2000 21:26:02 +0100 Daniel Phillips
> <[EMAIL PROTECTED]> wrote:
>
> > Hi Chris. I took your patch for a test drive under dbench and it seems
> > impressively stable under load, but there are performance problems.
> >
> >Test machine: 64
On Wednesday, December 27, 2000 21:26:02 +0100 Daniel Phillips
<[EMAIL PROTECTED]> wrote:
> Hi Chris. I took your patch for a test drive under dbench and it seems
> impressively stable under load, but there are performance problems.
>
>Test machine: 64 meg, 500 Mhz K6, IDE, Ext2, Bloc
Chris Mason wrote:
>
> Hi guys,
>
> Here's my latest code, which uses ll_rw_block for anon pages (or
> pages without a writepage func) when flush_dirty_buffers,
> sync_buffers, or fsync_inode_buffers are flushing things. This
> seems to have fixed my slowdown on 1k buffer sizes, but I
> haven't
On Tue, 26 Dec 2000, Chris Mason wrote:
>
> Hi guys,
>
> Here's my latest code, which uses ll_rw_block for anon pages (or
> pages without a writepage func) when flush_dirty_buffers,
> sync_buffers, or fsync_inode_buffers are flushing things. This
> seems to have fixed my slowdown on 1k buff
Hi guys,
Here's my latest code, which uses ll_rw_block for anon pages (or
pages without a writepage func) when flush_dirty_buffers,
sync_buffers, or fsync_inode_buffers are flushing things. This
seems to have fixed my slowdown on 1k buffer sizes, but I
haven't done extensive benchmarks yet.
O
On Saturday, December 23, 2000 11:02:53 -0800 Linus Torvalds
<[EMAIL PROTECTED]> wrote:
>
> Which is why I prefer the higher layers handling the dirty/uptodate/xxx
> bits.
>
Grin, I should have taken the hint when we talked about the buffer up to
date checks for block_read_full_page, it made
On Sat, 23 Dec 2000, Chris Mason wrote:
>
> I've updated to test13-pre4, and removed the hunk for submit_bh.
> Looks as though pre4 changed the submit_bh callers to clear the dirty
> bit, so my code does the same.
Basically, I wanted to think of "submit_bh()" as a pure IO thing. When we
call s
On Friday, December 22, 2000 21:26:33 -0200 Marcelo Tosatti
> If we use ll_rw_block directly on buffers of anonymous pages
> (page->mapping == &anon_space_mapping) instead using
> dirty_list_writepage() (which will end up calling block_write_anon_page)
> we can fix the buffer flushtime issue.
>
Chris Mason wrote:
> It is enough to leave buffer heads we don't flush on the dirty list (and
> redirty the page), they'll get written by a future loop through
> flush_dirty_pages, or by page_launder. We could use ll_rw_block instead,
> even though anon pages do have a writepage with this patch (
On Fri, 22 Dec 2000, Chris Mason wrote:
> It is enough to leave buffer heads we don't flush on the dirty list (and
> redirty the page), they'll get written by a future loop through
> flush_dirty_pages, or by page_launder. We could use ll_rw_block instead,
> even though anon pages do have a writ
On Friday, December 22, 2000 17:52:28 -0200 Marcelo Tosatti
<[EMAIL PROTECTED]> wrote:
> There is one more nasty issue to deal with.
>
> You only want to take into account the buffer flushtime if
> "check_flushtime" parameter is passed as true to flush_dirty_buffers
> (which is done by kupdat
On Friday, December 22, 2000 17:45:57 +0100 Daniel Phillips
<[EMAIL PROTECTED]> wrote:
[ flushing a page at a time in bdflush ]
> Um. Why cater to the uncommon case of 1K blocks? Just let
> bdflush/kupdated deal with them in the normal way - it's pretty
> efficient. Only try to do the clust
Chris Mason wrote:
>
> On Thursday, December 21, 2000 22:38:04 -0200 Marcelo Tosatti
><[EMAIL PROTECTED]> wrote:
> >
> > On Thu, 21 Dec 2000, Andreas Dilger wrote:
> >
> >> Marcelo Tosatti writes:
> >> > It seems your code has a problem with bh flush time.
> >> >
> >> > In flush_dirty_buffers(),
On Thursday, December 21, 2000 22:38:04 -0200 Marcelo Tosatti
<[EMAIL PROTECTED]> wrote:
>> Marcelo Tosatti writes:
>> > It seems your code has a problem with bh flush time.
>> >
>> > In flush_dirty_buffers(), a buffer may (if being called from kupdate)
>> > only be written in case its old eno
On Thursday, December 21, 2000 22:38:04 -0200 Marcelo Tosatti
<[EMAIL PROTECTED]> wrote:
>
> On Thu, 21 Dec 2000, Andreas Dilger wrote:
>
>> Marcelo Tosatti writes:
>> > It seems your code has a problem with bh flush time.
>> >
>> > In flush_dirty_buffers(), a buffer may (if being called fr
On Thursday, December 21, 2000 20:54:09 -0500 Alexander Viro <[EMAIL PROTECTED]> wrote:
>
>
> On Thu, 21 Dec 2000, Chris Mason wrote:
>
>> Obvious bug, block_write_full_page zeros out the bits past the end of
>> file every time. This should not be needed for normal file writes.
>
> Unfort
On Thu, 21 Dec 2000, Andreas Dilger wrote:
> Marcelo Tosatti writes:
> > It seems your code has a problem with bh flush time.
> >
> > In flush_dirty_buffers(), a buffer may (if being called from kupdate) only
> > be written in case its old enough. (bh->b_flushtime)
> >
> > If the flush happens
Marcelo Tosatti writes:
> It seems your code has a problem with bh flush time.
>
> In flush_dirty_buffers(), a buffer may (if being called from kupdate) only
> be written in case its old enough. (bh->b_flushtime)
>
> If the flush happens for an anonymous buffer, you'll end up writing all
> buffe
On Thu, 21 Dec 2000, Chris Mason wrote:
> Ok guys, I think I've taken Linus' suggestion to have buffer.c use its
> own writepage a bit too far. This patch marks pages dirty when the
> buffer head is marked dirty, and changes flush_dirty_buffers and
> sync_buffers to use writepage instead of l
On Thu, 21 Dec 2000, Chris Mason wrote:
> Obvious bug, block_write_full_page zeros out the bits past the end of
> file every time. This should not be needed for normal file writes.
Unfortunately, it _is_ needed for pageout path. mmap() the last page
of file. Dirty the data past the EOF (MMU
Ok guys, I think I've taken Linus' suggestion to have buffer.c use its
own writepage a bit too far. This patch marks pages dirty when the
buffer head is marked dirty, and changes flush_dirty_buffers and
sync_buffers to use writepage instead of ll_rw_block. The idea is
to allow filesystems t
On Tue, 19 Dec 2000, Daniel Phillips wrote:
> Marcelo Tosatti wrote:
> >
> > On Mon, 18 Dec 2000, Stephen C. Tweedie wrote:
> >
> > > Hi,
> > >
> > > On Sun, Dec 17, 2000 at 12:38:17AM -0200, Marcelo Tosatti wrote:
> > > > On Fri, 15 Dec 2000, Stephen C. Tweedie wrote:
> > > >
> > > > Stephen,
In article <[EMAIL PROTECTED]> you wrote:
>> I think the semantics of the filesystem specific ->flush and ->writepage
>> are not the same.
>>
>> Is ok for filesystem specific writepage() code to sync other "physically
>> contiguous" dirty pages with reference to the one requested by
>> writepage(
Marcelo Tosatti wrote:
>
> On Mon, 18 Dec 2000, Stephen C. Tweedie wrote:
>
> > Hi,
> >
> > On Sun, Dec 17, 2000 at 12:38:17AM -0200, Marcelo Tosatti wrote:
> > > On Fri, 15 Dec 2000, Stephen C. Tweedie wrote:
> > >
> > > Stephen,
> > >
> > > The ->flush() operation (which we've been discussing
On Mon, 18 Dec 2000, Stephen C. Tweedie wrote:
> Hi,
>
> On Sun, Dec 17, 2000 at 12:38:17AM -0200, Marcelo Tosatti wrote:
> > On Fri, 15 Dec 2000, Stephen C. Tweedie wrote:
> >
> > Stephen,
> >
> > The ->flush() operation (which we've been discussing a bit) would be very
> > useful now (mainl
Hi,
On Sun, Dec 17, 2000 at 12:38:17AM -0200, Marcelo Tosatti wrote:
> On Fri, 15 Dec 2000, Stephen C. Tweedie wrote:
>
> Stephen,
>
> The ->flush() operation (which we've been discussing a bit) would be very
> useful now (mainly for XFS).
>
> At page_launder(), we can call ->flush() if the gi
Hi,
On Sat, Dec 16, 2000 at 07:08:02PM -0600, Russell Cattelan wrote:
> > There is a very clean way of doing this with address spaces. It's
> > something I would like to see done properly for 2.5: eliminate all
> > knowledge of buffer_heads from the VM layer. It would be pretty
> > simple to re
On Sat, 16 Dec 2000, Russell Cattelan wrote:
> >
> I'm curious about this.
> Does the mean reiserFS is doing all of it's own buffer management?
>
> This would seem a little redundant with what is already in the kernel?
>
For metadata only reiserfs does its own write management. The buffers
co
On Fri, 15 Dec 2000, Stephen C. Tweedie wrote:
> Hi,
>
> On Fri, Dec 15, 2000 at 02:00:19AM -0500, Alexander Viro wrote:
> > On Thu, 14 Dec 2000, Linus Torvalds wrote:
> >
> > Just one: any fs that really cares about completion callback is very likely
> > to be picky about the requests orderin
"Stephen C. Tweedie" wrote:
> Hi,
>
> On Fri, Dec 15, 2000 at 02:00:19AM -0500, Alexander Viro wrote:
> > On Thu, 14 Dec 2000, Linus Torvalds wrote:
> >
> > Just one: any fs that really cares about completion callback is very likely
> > to be picky about the requests ordering. So sync_buffers() i
Chris Mason wrote:
> On Fri, 15 Dec 2000, Alexander Viro wrote:
>
> > Just one: any fs that really cares about completion callback is very likely
> > to be picky about the requests ordering. So sync_buffers() is very unlikely
> > to be useful anyway.
> >
> Somewhat. I guess there are at least tw
Alexander Viro wrote:
> On Thu, 14 Dec 2000, Linus Torvalds wrote:
>
> > Good point.
> >
> > This actually looks fairly nasty to fix. The obvious fix would be to not
> > put such buffers on the dirty list at all, and instead rely on the VM
> > layer calling "writepage()" when it wants to push out
Linus Torvalds wrote:
> On Thu, 14 Dec 2000, Russell Cattelan wrote:
> >
> > Ok one more wrinkle.
> > sync_buffers calls ll_rw_block, this is going to have the same problem as
> > calling ll_rw_block directly.
>
> Good point.
>
> This actually looks fairly nasty to fix. The obvious fix would be t
On Sat, 16 Dec 2000, Linus Torvalds wrote:
> Your patch looks fine, although I'd personally prefer this one even more:
>
Yes, that looks better and works here.
-chris
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Pleas
On Sat, 16 Dec 2000, Chris Mason wrote:
>
> In other words, after calling reiserfs_get_block, the buffer might be
> mapped and uptodate, with no i/o required in block_read_full_page
>
> The following patch to block_read_full_page fixes things for me, and seems
> like a good idea in general. I
On Fri, 15 Dec 2000, Linus Torvalds wrote:
[ writepage for anon buffers ]
>
> It might be 10 lines of change, and obviously correct.
>
I'll give this a try, it will be interesting regardless of if it is simple
enough for kernel inclusion.
On a related note, I hit a snag porting reiserfs int
On Sat, 16 Dec 2000, Jeff Chua wrote:
>
> > Now, I also agree that we should be able to clean this up properly for
> > 2.5.x, and actually do exactly this for the anonymous buffers, so that
> > the VM no longer needs to worry about buffer knowledge, and fs/buffer.c
> > becomes just another user
> Now, I also agree that we should be able to clean this up properly for
> 2.5.x, and actually do exactly this for the anonymous buffers, so that
> the VM no longer needs to worry about buffer knowledge, and fs/buffer.c
> becomes just another user of the writepage functionality. That is not
> all
In article <[EMAIL PROTECTED]>,
Stephen C. Tweedie <[EMAIL PROTECTED]> wrote:
>
>> What we really need is a way for VFS/VM to pass the pressure on filesystem.
>> That's it. If fs wants unusual completions for requests - let it have its
>> own queueing mechanism and submit these requests when it fi
Hi,
On Fri, Dec 15, 2000 at 02:00:19AM -0500, Alexander Viro wrote:
> On Thu, 14 Dec 2000, Linus Torvalds wrote:
>
> Just one: any fs that really cares about completion callback is very likely
> to be picky about the requests ordering. So sync_buffers() is very unlikely
> to be useful anyway.
>
On Fri, 15 Dec 2000, Alexander Viro wrote:
> Just one: any fs that really cares about completion callback is very likely
> to be picky about the requests ordering. So sync_buffers() is very unlikely
> to be useful anyway.
>
Somewhat. I guess there are at least two ways to do it. First flush
On Thu, 14 Dec 2000, Linus Torvalds wrote:
> Good point.
>
> This actually looks fairly nasty to fix. The obvious fix would be to not
> put such buffers on the dirty list at all, and instead rely on the VM
> layer calling "writepage()" when it wants to push out the pages.
> That would be the
On Thu, 14 Dec 2000, Russell Cattelan wrote:
>
> Ok one more wrinkle.
> sync_buffers calls ll_rw_block, this is going to have the same problem as
> calling ll_rw_block directly.
Good point.
This actually looks fairly nasty to fix. The obvious fix would be to not
put such buffers on the dirty
On Thu, 14 Dec 2000, Russell Cattelan wrote:
>
> So one more observation in
> filemap_sync_pte
>
> lock_page(page);
> error = filemap_write_page(page, 1);
> -> UnlockPage(page);
> This unlock page was removed? is that correct?
Yes. The "writepage" thing changed: "struct file" disappeared (
In article <[EMAIL PROTECTED]>,
Russell Cattelan <[EMAIL PROTECTED]> wrote:
>This would seem to be an error on the part of ll_rw_block.
>Setting b_end_io to a default handler without checking to see
>a callback has already been defined defeats the purpose of having
>a function op.
No.
It just m
This would seem to be an error on the part of ll_rw_block.
Setting b_end_io to a default handler without checking to see
a callback has already been defined defeats the purpose of having
a function op.
void ll_rw_block(int rw, int nr, struct buffer_head * bhs[])
{
@@ -928,7 +1046,8 @@
64 matches
Mail list logo
