From: Andrew Morton <akpm@linux-foundation.org>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>,
<linux-usb-devel@lists.sourceforge.net>,
Pete Zaitcev <zaitcev@redhat.com>, Greg KH <gregkh@suse.de>,
Kumar Gala <galak@kernel.crashing.org>,
Linux Kernel list <linux-kernel@vger.kernel.org>
Subject: Re: [linux-usb-devel] 2.6.20 kernel hang with USB drive and vfat doing ftruncate
Date: Wed, 21 Feb 2007 13:31:12 -0800 [thread overview]
Message-ID: <20070221133112.aec2bdac.akpm@linux-foundation.org> (raw)
In-Reply-To: <Pine.LNX.4.44L0.0702211621310.3435-100000@iolanthe.rowland.org>
On Wed, 21 Feb 2007 16:22:17 -0500 (EST)
Alan Stern <stern@rowland.harvard.edu> wrote:
> On Wed, 21 Feb 2007, Andrew Morton wrote:
>
> > > > It seems like usb-storage and aio are completely off in the weeds.
> > > > Ideas?
> > >
> > > It seems usb-storage should remove some kmalloc and use mempool() for
> > > urb... Is someone working on this? And idea?
> >
> > I think Pete said that we're supposed to be using GFP_NOIO in there.
>
> We _are_ using it.
How admirably prompt.
> > Not that it'll help much: the VM calls throttle_vm_writeout() for GFP_NOIO
> > and GFP_NOFS allocations, which is a bug. Because if the caller holds
> > locks which prevent filesystem or IO progress, we deadlock.
> >
> > I'll fix the VM if someone else fixes USB ;)
>
> What else needs to be fixed?
Would be nice if someone can confirm that this fixes it:
From: Andrew Morton <akpm@linux-foundation.org>
throttle_vm_writeout() is designed to wait for the dirty levels to subside.
But if the caller holds IO or FS locks, we might be holding up that writeout.
So change it to take a single nap to give other devices a chance to clean some
memory, then return.
Cc: Nick Piggin <nickpiggin@yahoo.com.au>
Cc: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
Cc: Kumar Gala <galak@kernel.crashing.org>
Cc: Pete Zaitcev <zaitcev@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
include/linux/writeback.h | 2 +-
mm/page-writeback.c | 13 +++++++++++--
mm/vmscan.c | 2 +-
3 files changed, 13 insertions(+), 4 deletions(-)
diff -puN mm/vmscan.c~throttle_vm_writeout-dont-loop-on-gfp_nofs-and-gfp_noio-allocations mm/vmscan.c
--- a/mm/vmscan.c~throttle_vm_writeout-dont-loop-on-gfp_nofs-and-gfp_noio-allocations
+++ a/mm/vmscan.c
@@ -952,7 +952,7 @@ static unsigned long shrink_zone(int pri
}
}
- throttle_vm_writeout();
+ throttle_vm_writeout(sc->gfp_mask);
atomic_dec(&zone->reclaim_in_progress);
return nr_reclaimed;
diff -puN mm/page-writeback.c~throttle_vm_writeout-dont-loop-on-gfp_nofs-and-gfp_noio-allocations mm/page-writeback.c
--- a/mm/page-writeback.c~throttle_vm_writeout-dont-loop-on-gfp_nofs-and-gfp_noio-allocations
+++ a/mm/page-writeback.c
@@ -296,11 +296,21 @@ void balance_dirty_pages_ratelimited_nr(
}
EXPORT_SYMBOL(balance_dirty_pages_ratelimited_nr);
-void throttle_vm_writeout(void)
+void throttle_vm_writeout(gfp_t gfp_mask)
{
long background_thresh;
long dirty_thresh;
+ if ((gfp_mask & (__GFP_FS|__GFP_IO)) != (__GFP_FS|__GFP_IO)) {
+ /*
+ * The caller might hold locks which can prevert IO completion
+ * or progress in the filesystem. So we cannot just sit here
+ * waiting for IO to complete.
+ */
+ congestion_wait(WRITE, HZ/10);
+ return;
+ }
+
for ( ; ; ) {
get_dirty_limits(&background_thresh, &dirty_thresh, NULL);
@@ -317,7 +327,6 @@ void throttle_vm_writeout(void)
}
}
-
/*
* writeback at least _min_pages, and keep writing until the amount of dirty
* memory is less than the background threshold, or until we're all clean.
diff -puN include/linux/writeback.h~throttle_vm_writeout-dont-loop-on-gfp_nofs-and-gfp_noio-allocations include/linux/writeback.h
--- a/include/linux/writeback.h~throttle_vm_writeout-dont-loop-on-gfp_nofs-and-gfp_noio-allocations
+++ a/include/linux/writeback.h
@@ -84,7 +84,7 @@ static inline void wait_on_inode(struct
int wakeup_pdflush(long nr_pages);
void laptop_io_completion(void);
void laptop_sync_completion(void);
-void throttle_vm_writeout(void);
+void throttle_vm_writeout(gfp_t gfp_mask);
/* These are exported to sysctl. */
extern int dirty_background_ratio;
_
next prev parent reply other threads:[~2007-02-21 21:31 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-02-16 19:54 2.6.20 kernel hang with USB drive and vfat doing ftruncate Kumar Gala
2007-02-18 16:10 ` OGAWA Hirofumi
2007-02-19 21:58 ` Kumar Gala
2007-02-19 22:19 ` OGAWA Hirofumi
2007-02-19 22:27 ` Kumar Gala
2007-02-20 17:20 ` OGAWA Hirofumi
2007-02-19 22:06 ` Kumar Gala
2007-02-21 20:18 ` OGAWA Hirofumi
2007-02-21 20:57 ` Andrew Morton
2007-02-21 21:22 ` [linux-usb-devel] " Alan Stern
2007-02-21 21:31 ` Andrew Morton [this message]
2007-02-21 21:50 ` Alan Stern
2007-02-21 22:54 ` Andrew Morton
2007-02-22 7:40 ` Kumar Gala
2007-02-22 18:20 ` Kumar Gala
2007-02-22 21:57 ` Andrew Morton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20070221133112.aec2bdac.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=galak@kernel.crashing.org \
--cc=gregkh@suse.de \
--cc=hirofumi@mail.parknet.co.jp \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb-devel@lists.sourceforge.net \
--cc=stern@rowland.harvard.edu \
--cc=zaitcev@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.