From: Andi Kleen <ak@muc.de>
To: Andrew Morton <akpm@osdl.org>
Cc: largret@gmail.com, 76306.1226@compuserve.com,
linux-kernel@vger.kernel.org, axboe@suse.de
Subject: Re: OOM-killer too aggressive?
Date: 27 Feb 2006 00:47:36 +0100
Date: Mon, 27 Feb 2006 00:47:36 +0100 [thread overview]
Message-ID: <20060226234736.GA91959@muc.de> (raw)
In-Reply-To: <20060226133140.4cf05ea5.akpm@osdl.org>
> hm, OK. I suppose we can hit it with the big hammer, but I'd be reluctant
> to merge this patch because it has the potential to hide problems, such as
> the as-yet-unfixed bio-uses-ZONE_DMA one.
Better would be to fix the block layer. I think something like that
would be better: (only lightly tested - it booted on a 6GB x86-64 box)
It is over pessimistic on systems with real IOMMU that can even remap
to DMA addresses < 4GB - in the future those might want to define
some ARCH_HAS macro so it can be checked here.
Does that patch fix the problem?
That said adding GFP_NORETRY to the floppy allocation is probably still a good
idea. I will do that change here.
-Andi
Disable block layer bouncing for most memory on 64bit systems
The low level PCI DMA mapping functions should handle it in most cases.
This should fix problems with depleting the DMA zone early. The old
code used precious GFP_DMA memory in many cases where it was not needed.
Signed-off-by: Andi Kleen <ak@suse.de>
Index: linux/block/ll_rw_blk.c
===================================================================
--- linux.orig/block/ll_rw_blk.c
+++ linux/block/ll_rw_blk.c
@@ -625,26 +625,32 @@ static inline int ordered_bio_endio(stru
* Different hardware can have different requirements as to what pages
* it can do I/O directly to. A low level driver can call
* blk_queue_bounce_limit to have lower memory pages allocated as bounce
- * buffers for doing I/O to pages residing above @page. By default
- * the block layer sets this to the highest numbered "low" memory page.
+ * buffers for doing I/O to pages residing above @page.
**/
void blk_queue_bounce_limit(request_queue_t *q, u64 dma_addr)
{
unsigned long bounce_pfn = dma_addr >> PAGE_SHIFT;
+ int dma = 0;
- /*
- * set appropriate bounce gfp mask -- unfortunately we don't have a
- * full 4GB zone, so we have to resort to low memory for any bounces.
- * ISA has its own < 16MB zone.
- */
- if (bounce_pfn < blk_max_low_pfn) {
+ q->bounce_gfp = GFP_NOIO;
+#if BITS_PER_LONG == 64
+ /* Assume anything >= 4GB can be handled by IOMMU.
+ Actually some IOMMUs can handle everything, but I don't
+ know of a way to test this here. */
+ if (bounce_pfn < (0xffffffff>>PAGE_SHIFT))
+ dma = 1;
+ q->bounce_pfn = max_low_pfn;
+#else
+ if (bounce_pfn < blk_max_low_pfn)
+ dma = 1;
+ q->bounce_pfn = bounce_pfn;
+#endif
+ if (dma) {
BUG_ON(dma_addr < BLK_BOUNCE_ISA);
init_emergency_isa_pool();
q->bounce_gfp = GFP_NOIO | GFP_DMA;
- } else
- q->bounce_gfp = GFP_NOIO;
-
- q->bounce_pfn = bounce_pfn;
+ q->bounce_pfn = bounce_pfn;
+ }
}
EXPORT_SYMBOL(blk_queue_bounce_limit);
next prev parent reply other threads:[~2006-02-26 23:47 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-02-26 14:35 OOM-killer too aggressive? Chuck Ebbert
2006-02-26 18:21 ` Andrew Morton
2006-02-26 20:39 ` Andi Kleen
2006-02-26 21:04 ` Andrew Morton
2006-02-26 21:06 ` Chris Largret
2006-02-26 21:31 ` Andrew Morton
2006-02-26 23:00 ` Chris Largret
2006-02-27 0:20 ` Andrew Morton
2006-02-27 1:01 ` Chris Largret
2006-02-27 1:57 ` Andrew Morton
2006-02-27 6:34 ` Chris Largret
2006-02-26 23:47 ` Andi Kleen [this message]
2006-02-26 23:51 ` Andi Kleen
2006-02-27 22:30 ` Christoph Lameter
2006-02-28 0:41 ` Andi Kleen
2006-02-28 0:59 ` Andrew Morton
2006-02-28 1:03 ` Christoph Lameter
2006-02-28 1:25 ` Andi Kleen
2006-02-28 1:38 ` Andrew Morton
2006-02-28 12:09 ` Andi Kleen
[not found] <5KvnZ-4uN-27@gated-at.bofh.it>
2006-02-26 18:39 ` Robert Hancock
2006-02-26 21:56 ` Marcelo Tosatti
2006-02-26 20:56 ` Chris Largret
2006-02-27 0:22 ` Marcelo Tosatti
2006-02-27 1:48 ` Chris Largret
2006-02-27 15:47 ` Marcelo Tosatti
-- strict thread matches above, loose matches on Subject: below --
2006-02-26 23:32 Chuck Ebbert
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=20060226234736.GA91959@muc.de \
--to=ak@muc.de \
--cc=76306.1226@compuserve.com \
--cc=akpm@osdl.org \
--cc=axboe@suse.de \
--cc=largret@gmail.com \
--cc=linux-kernel@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox