> > On Thu, 22 Feb 2007 08:42:26 +0100 Miklos Szeredi <[EMAIL PROTECTED]> wrote:
> > > >
> > > > Index: linux/mm/page-writeback.c
> > > > ===
> > > > --- linux.orig/mm/page-writeback.c 2007-02-19 17:32:41.0
> > > > +0100
> On Thu, 22 Feb 2007 08:42:26 +0100 Miklos Szeredi <[EMAIL PROTECTED]> wrote:
> > >
> > > Index: linux/mm/page-writeback.c
> > > ===
> > > --- linux.orig/mm/page-writeback.c2007-02-19 17:32:41.0
> > > +0100
> > > +++
> > How about this?
>
> I still don't understand this bug.
>
> > Solves the FUSE deadlock, but not the throttle_vm_writeout() one.
> > I'll try to tackle that one as well.
> >
> > If the per-bdi dirty counter goes below 16, balance_dirty_pages()
> > returns.
> >
> > Does the constant need to tu
On Mon, 19 Feb 2007 18:11:55 +0100
Miklos Szeredi <[EMAIL PROTECTED]> wrote:
> How about this?
I still don't understand this bug.
> Solves the FUSE deadlock, but not the throttle_vm_writeout() one.
> I'll try to tackle that one as well.
>
> If the per-bdi dirty counter goes below 16, balance_di
On Tue, Feb 20, 2007 at 09:47:11AM +0100, Miklos Szeredi wrote:
> > > How about this?
> > >
> > > Solves the FUSE deadlock, but not the throttle_vm_writeout() one.
> > > I'll try to tackle that one as well.
> > >
> > > If the per-bdi dirty counter goes below 16, balance_dirty_pages()
> > > return
> > > > > In general, writepage is supposed to do work without blocking on
> > > > > expensive locks that will get pdflush and dirty reclaim stuck in this
> > > > > fashion. You'll probably have to take the same approach reiserfs does
> > > > > in data=journal mode, which is leaving the page dirty
> > How about this?
> >
> > Solves the FUSE deadlock, but not the throttle_vm_writeout() one.
> > I'll try to tackle that one as well.
> >
> > If the per-bdi dirty counter goes below 16, balance_dirty_pages()
> > returns.
> >
> > Does the constant need to tunable? If it's too large, then the gl
On Mon, Feb 19, 2007 at 02:14:15AM +0100, Miklos Szeredi wrote:
> > > > In general, writepage is supposed to do work without blocking on
> > > > expensive locks that will get pdflush and dirty reclaim stuck in this
> > > > fashion. You'll probably have to take the same approach reiserfs does
> > >
On Mon, Feb 19, 2007 at 06:11:55PM +0100, Miklos Szeredi wrote:
> How about this?
>
> Solves the FUSE deadlock, but not the throttle_vm_writeout() one.
> I'll try to tackle that one as well.
>
> If the per-bdi dirty counter goes below 16, balance_dirty_pages()
> returns.
>
> Does the constant ne
> Solves the FUSE deadlock, but not the throttle_vm_writeout() one.
> I'll try to tackle that one as well.
>
> If the per-bdi dirty counter goes below 16, balance_dirty_pages()
> returns.
>
> Does the constant need to tunable? If it's too large, then the global
> threshold is more easily exceede
How about this?
Solves the FUSE deadlock, but not the throttle_vm_writeout() one.
I'll try to tackle that one as well.
If the per-bdi dirty counter goes below 16, balance_dirty_pages()
returns.
Does the constant need to tunable? If it's too large, then the global
threshold is more easily exceed
> > > In general, writepage is supposed to do work without blocking on
> > > expensive locks that will get pdflush and dirty reclaim stuck in this
> > > fashion. You'll probably have to take the same approach reiserfs does
> > > in data=journal mode, which is leaving the page dirty if fuse_get_req
On Mon, Feb 19, 2007 at 01:54:31AM +0100, Miklos Szeredi wrote:
> > > > > > If so, writes to B will decrease the dirty memory threshold.
> > > > >
> > > > > Yes, but not by enough. Say A dirties a 1100 pages, limit is 1000.
> > > > > Some pages queued for writeback (doesn't matter how much). B w
> > > > > If so, writes to B will decrease the dirty memory threshold.
> > > >
> > > > Yes, but not by enough. Say A dirties a 1100 pages, limit is 1000.
> > > > Some pages queued for writeback (doesn't matter how much). B writes
> > > > back 1, 1099 dirty remain in A, zero in B. balance_dirty_
On Mon, Feb 19, 2007 at 01:25:21AM +0100, Miklos Szeredi wrote:
> > > > If so, writes to B will decrease the dirty memory threshold.
> > >
> > > Yes, but not by enough. Say A dirties a 1100 pages, limit is 1000.
> > > Some pages queued for writeback (doesn't matter how much). B writes
> > > back
> > > > If so, writes to B will decrease the dirty memory threshold.
> > >
> > > Yes, but not by enough. Say A dirties a 1100 pages, limit is 1000.
> > > Some pages queued for writeback (doesn't matter how much). B writes
> > > back 1, 1099 dirty remain in A, zero in B. balance_dirty_pages() fo
> --- a/fs/fs-writeback.c~a
> +++ a/fs/fs-writeback.c
> @@ -356,7 +356,7 @@ int generic_sync_sb_inodes(struct super_
> continue; /* Skip a congested blockdev */
> }
>
> - if (wbc->bdi && bdi != wbc->bdi) {
> + if (wbc->bdi
> > > If so, writes to B will decrease the dirty memory threshold.
> >
> > Yes, but not by enough. Say A dirties a 1100 pages, limit is 1000.
> > Some pages queued for writeback (doesn't matter how much). B writes
> > back 1, 1099 dirty remain in A, zero in B. balance_dirty_pages() for
> > B do
On Mon, 19 Feb 2007 00:22:11 +0100 Miklos Szeredi <[EMAIL PROTECTED]> wrote:
> > If so, writes to B will decrease the dirty memory threshold.
>
> Yes, but not by enough. Say A dirties a 1100 pages, limit is 1000.
> Some pages queued for writeback (doesn't matter how much). B writes
> back 1, 10
> > > > I was testing the new fuse shared writable mmap support, and finding
> > > > that bash-shared-mapping deadlocks (which isn't so strange ;). What
> > > > is more strange is that this is not an OOM situation at all, with
> > > > plenty of free and cached pages.
> > > >
> > > > A little more
On Sun, 18 Feb 2007 23:50:14 +0100 Miklos Szeredi <[EMAIL PROTECTED]> wrote:
> > > I was testing the new fuse shared writable mmap support, and finding
> > > that bash-shared-mapping deadlocks (which isn't so strange ;). What
> > > is more strange is that this is not an OOM situation at all, with
> Andrew Morton wrote:
> > On Sun, 18 Feb 2007 19:28:18 +0100 Miklos Szeredi <[EMAIL PROTECTED]> wrote:
> >
> >> I was testing the new fuse shared writable mmap support, and finding
> >> that bash-shared-mapping deadlocks (which isn't so strange ;). What
> >> is more strange is that this is not a
> > I was testing the new fuse shared writable mmap support, and finding
> > that bash-shared-mapping deadlocks (which isn't so strange ;). What
> > is more strange is that this is not an OOM situation at all, with
> > plenty of free and cached pages.
> >
> > A little more investigation shows tha
Andrew Morton wrote:
On Sun, 18 Feb 2007 19:28:18 +0100 Miklos Szeredi <[EMAIL PROTECTED]> wrote:
I was testing the new fuse shared writable mmap support, and finding
that bash-shared-mapping deadlocks (which isn't so strange ;). What
is more strange is that this is not an OOM situation at all
On Sun, 18 Feb 2007 19:28:18 +0100 Miklos Szeredi <[EMAIL PROTECTED]> wrote:
> I was testing the new fuse shared writable mmap support, and finding
> that bash-shared-mapping deadlocks (which isn't so strange ;). What
> is more strange is that this is not an OOM situation at all, with
> plenty of
I was testing the new fuse shared writable mmap support, and finding
that bash-shared-mapping deadlocks (which isn't so strange ;). What
is more strange is that this is not an OOM situation at all, with
plenty of free and cached pages.
A little more investigation shows that a similar deadlock hap
26 matches
Mail list logo
