From: Jesse Barnes <jesse.barnes@intel.com>
To: Christoph Lameter <clameter@sgi.com>
Cc: Martin Bligh <mbligh@mbligh.org>, Andi Kleen <ak@suse.de>,
Alan Cox <alan@lxorguk.ukuu.org.uk>,
akpm@google.com, linux-kernel@vger.kernel.org,
Christoph Hellwig <hch@infradead.org>,
James Bottomley <James.Bottomley@steeleye.com>,
linux-mm@kvack.org
Subject: Re: [RFC] Initial alpha-0 for new page allocator API
Date: Fri, 22 Sep 2006 13:41:44 -0700 [thread overview]
Message-ID: <200609221341.44354.jesse.barnes@intel.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0609221321280.9181@schroedinger.engr.sgi.com>
On Friday, September 22, 2006 1:23 pm, Christoph Lameter wrote:
> Here is an iniitial patch of alloc_pages_range (untested, compiles).
> Directed reclaim missing. Feedback wanted. There are some comments in
> the patch where I am at the boundary of my knowledge and it would be
> good if someone could supply the info needed.
>
> Index: linux-2.6.18-rc7-mm1/arch/i386/kernel/pci-dma.c
> ===================================================================
> --- linux-2.6.18-rc7-mm1.orig/arch/i386/kernel/pci-dma.c 2006-09-22
> 15:10:42.246731179 -0500 +++
> linux-2.6.18-rc7-mm1/arch/i386/kernel/pci-dma.c 2006-09-22
> 15:11:10.449709078 -0500 @@ -26,6 +26,8 @@ void
> *dma_alloc_coherent(struct device *
> dma_addr_t *dma_handle, gfp_t gfp)
> {
> void *ret;
> + unsigned long low = 0L;
> + unsigned long high = 0xffffffff;
> struct dma_coherent_mem *mem = dev ? dev->dma_mem : NULL;
> int order = get_order(size);
> /* ignore region specifiers */
> @@ -44,10 +46,14 @@ void *dma_alloc_coherent(struct device *
> return NULL;
> }
>
> - if (dev == NULL || (dev->coherent_dma_mask < 0xffffffff))
> - gfp |= GFP_DMA;
> + if (dev == NULL)
> + /* Apply safe ISA LIMITS */
> + high = 16*1024*1024L;
> + else
> + if (dev->coherent_dma_mask < 0xffffffff)
> + high = dev->coherent_dma_mask;
With your alloc_pages_range this check can go away. I think only the dev
== NULL check is needed with this scheme since it looks like there's no
way (currently) for ISA devices to store their masks for later
consultation by arch code?
> + /*
> + * Is there an upper/lower limit of installed memory that we could
> + * check against instead of -1 ? The less memory installed the less
> + * the chance that we would have to do the expensive range search.
> + */
> + if (high == -1L && low == 0L)
> + return alloc_pages(gfp_flags, order);
There's max_pfn, but on machines with large memory holes using it might not
help much.
Jesse
WARNING: multiple messages have this Message-ID (diff)
From: Jesse Barnes <jesse.barnes@intel.com>
To: Christoph Lameter <clameter@sgi.com>
Cc: Martin Bligh <mbligh@mbligh.org>, Andi Kleen <ak@suse.de>,
Alan Cox <alan@lxorguk.ukuu.org.uk>,
akpm@google.com, linux-kernel@vger.kernel.org,
Christoph Hellwig <hch@infradead.org>,
James Bottomley <James.Bottomley@steeleye.com>,
linux-mm@kvack.org
Subject: Re: [RFC] Initial alpha-0 for new page allocator API
Date: Fri, 22 Sep 2006 13:41:44 -0700 [thread overview]
Message-ID: <200609221341.44354.jesse.barnes@intel.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0609221321280.9181@schroedinger.engr.sgi.com>
On Friday, September 22, 2006 1:23 pm, Christoph Lameter wrote:
> Here is an iniitial patch of alloc_pages_range (untested, compiles).
> Directed reclaim missing. Feedback wanted. There are some comments in
> the patch where I am at the boundary of my knowledge and it would be
> good if someone could supply the info needed.
>
> Index: linux-2.6.18-rc7-mm1/arch/i386/kernel/pci-dma.c
> ===================================================================
> --- linux-2.6.18-rc7-mm1.orig/arch/i386/kernel/pci-dma.c 2006-09-22
> 15:10:42.246731179 -0500 +++
> linux-2.6.18-rc7-mm1/arch/i386/kernel/pci-dma.c 2006-09-22
> 15:11:10.449709078 -0500 @@ -26,6 +26,8 @@ void
> *dma_alloc_coherent(struct device *
> dma_addr_t *dma_handle, gfp_t gfp)
> {
> void *ret;
> + unsigned long low = 0L;
> + unsigned long high = 0xffffffff;
> struct dma_coherent_mem *mem = dev ? dev->dma_mem : NULL;
> int order = get_order(size);
> /* ignore region specifiers */
> @@ -44,10 +46,14 @@ void *dma_alloc_coherent(struct device *
> return NULL;
> }
>
> - if (dev == NULL || (dev->coherent_dma_mask < 0xffffffff))
> - gfp |= GFP_DMA;
> + if (dev == NULL)
> + /* Apply safe ISA LIMITS */
> + high = 16*1024*1024L;
> + else
> + if (dev->coherent_dma_mask < 0xffffffff)
> + high = dev->coherent_dma_mask;
With your alloc_pages_range this check can go away. I think only the dev
== NULL check is needed with this scheme since it looks like there's no
way (currently) for ISA devices to store their masks for later
consultation by arch code?
> + /*
> + * Is there an upper/lower limit of installed memory that we could
> + * check against instead of -1 ? The less memory installed the less
> + * the chance that we would have to do the expensive range search.
> + */
> + if (high == -1L && low == 0L)
> + return alloc_pages(gfp_flags, order);
There's max_pfn, but on machines with large memory holes using it might not
help much.
Jesse
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2006-09-22 20:43 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-09-22 4:02 [RFC] Initial alpha-0 for new page allocator API Christoph Lameter
2006-09-22 4:02 ` Christoph Lameter
2006-09-22 6:17 ` Andi Kleen
2006-09-22 6:17 ` Andi Kleen
2006-09-22 16:35 ` Christoph Lameter
2006-09-22 16:35 ` Christoph Lameter
2006-09-22 19:10 ` Andi Kleen
2006-09-22 19:10 ` Andi Kleen
2006-09-22 19:17 ` Christoph Lameter
2006-09-22 19:17 ` Christoph Lameter
2006-09-22 19:24 ` Martin Bligh
2006-09-22 19:24 ` Martin Bligh
2006-09-22 20:10 ` Alan Cox
2006-09-22 20:10 ` Alan Cox
2006-09-22 20:02 ` Andi Kleen
2006-09-22 20:02 ` Andi Kleen
2006-09-22 20:14 ` Martin Bligh
2006-09-22 20:14 ` Martin Bligh
2006-09-22 20:23 ` Christoph Lameter
2006-09-22 20:23 ` Christoph Lameter
2006-09-22 20:41 ` Jesse Barnes [this message]
2006-09-22 20:41 ` Jesse Barnes
2006-09-22 21:01 ` Christoph Lameter
2006-09-22 21:01 ` Christoph Lameter
2006-09-22 21:14 ` Jesse Barnes
2006-09-22 21:14 ` Jesse Barnes
2006-09-22 21:21 ` Christoph Lameter
2006-09-22 21:21 ` Christoph Lameter
2006-09-22 20:48 ` Andi Kleen
2006-09-22 20:48 ` Andi Kleen
2006-09-22 21:13 ` Christoph Lameter
2006-09-22 21:13 ` Christoph Lameter
2006-09-22 21:32 ` Christoph Lameter
2006-09-22 21:32 ` Christoph Lameter
2006-09-22 23:34 ` More thoughts on getting rid of ZONE_DMA Andi Kleen
2006-09-22 23:34 ` Andi Kleen
2006-09-23 0:23 ` Christoph Lameter
2006-09-23 0:23 ` Christoph Lameter
2006-09-23 0:39 ` Andi Kleen
2006-09-23 0:39 ` Andi Kleen
2006-09-23 0:25 ` Christoph Lameter
2006-09-23 0:25 ` Christoph Lameter
2006-09-23 0:37 ` Andi Kleen
2006-09-23 0:37 ` Andi Kleen
2006-09-24 2:13 ` Christoph Lameter
2006-09-24 2:13 ` Christoph Lameter
2006-09-24 2:36 ` Martin J. Bligh
2006-09-24 2:36 ` Martin J. Bligh
2006-09-24 7:26 ` Andi Kleen
2006-09-24 7:26 ` Andi Kleen
2006-09-24 7:19 ` Andi Kleen
2006-09-24 7:19 ` Andi Kleen
2006-09-22 17:36 ` [RFC] Initial alpha-0 for new page allocator API Christoph Lameter
2006-09-22 17:36 ` Christoph Lameter
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=200609221341.44354.jesse.barnes@intel.com \
--to=jesse.barnes@intel.com \
--cc=James.Bottomley@steeleye.com \
--cc=ak@suse.de \
--cc=akpm@google.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=clameter@sgi.com \
--cc=hch@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mbligh@mbligh.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 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.