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
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.
>
>
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
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
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
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.
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
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
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
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
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 to
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() from
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 everything bdflush
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.
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.4.0. The
biggest
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, 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
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
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 Marcelo )
Yes
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
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
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 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
>
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
you can
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 one being
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.
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
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"),
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
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:
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 meg, 500 Mhz
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 through
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 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,
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
>
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 done
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,
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
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.
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.
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 buffer
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
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 == _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
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 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.
Ok,
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
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 sense
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
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
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
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
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
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
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.
>
>
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.
Unfortunately, it
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 from kupdate)
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 enough.
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(), a buffer may (if being
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
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 kupdate).
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
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
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
>
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
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
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
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
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
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
buffers
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 for an
74 matches
Mail list logo
