From: Andi Kleen <ak@suse.de>
To: Christoph Lameter <clameter@sgi.com>
Cc: Martin Bligh <mbligh@mbligh.org>,
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 21:10:25 +0200 [thread overview]
Message-ID: <200609222110.25118.ak@suse.de> (raw)
In-Reply-To: <Pine.LNX.4.64.0609220934040.7083@schroedinger.engr.sgi.com>
On Friday 22 September 2006 18:35, Christoph Lameter wrote:
> On Fri, 22 Sep 2006, Andi Kleen wrote:
>
> > On Friday 22 September 2006 06:02, Christoph Lameter wrote:
> > > We have repeatedly discussed the problems of devices having varying
> > > address range requirements for doing DMA.
> >
> > We already have such an API. dma_alloc_coherent(). Device drivers
> > are not supposed to mess with GFP_DMA* directly anymore for quite
> > some time.
>
> Device drivers need to be able to indicate ranges of addresses that may be
> different from ZONE_DMA. This is an attempt to come up with a future
> scheme that does no longer rely on device drivers referring to zoies.
We already have that scheme. Any existing driver should be already converted
away from GFP_DMA towards dma_*/pci_*. dma_* knows all the magic
how to get memory for the various ranges. No need to mess up the
main allocator.
Anyways, i suppose what could be added as a fallback would be a
really_slow_brute_force_try_to_get_something_in_this_range() allocator
that basically goes through the buddy lists freeing in >O(1)
and does some directed reclaim, but that would likely be a separate
path anyways and not need your new structure to impact the O(1)
allocator.
I am still unconvinced of the real need. The only gaping hole was
GFP_DMA32, which we fixed already.
Ok there is aacraid with its weird 2GB limit, but in case there are
really enough users running into this broken then then the really_slow_*
thing above would be likely fine. And those cards are slowly going
away too.
If we managed to resist for too long now is the wrong time.
> > I actually have my doubts it is a good idea to add that now. The devices
> > with weird requirements are steadily going away
> Hmm.... Martin?
Think of it this way: all the weird slow devices of 5-10 years ago have USB
interfaces today and that does 32bit just fine (=GFP_DMA32). And old 5-10 years old weird
devices are usually fine with 16MB of playground only.
Ok now I'm sure someone will come up with a counter example (hi Alan), but:
- Does the device really need more than 16MB?
- How often is it used on systems with >1/2GB with a 64bit kernel?
[consider that 64bit kernels don't support ISA]
- How many users of that particular thing around?
I think my point stands.
-And
WARNING: multiple messages have this Message-ID (diff)
From: Andi Kleen <ak@suse.de>
To: Christoph Lameter <clameter@sgi.com>
Cc: Martin Bligh <mbligh@mbligh.org>,
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 21:10:25 +0200 [thread overview]
Message-ID: <200609222110.25118.ak@suse.de> (raw)
In-Reply-To: <Pine.LNX.4.64.0609220934040.7083@schroedinger.engr.sgi.com>
On Friday 22 September 2006 18:35, Christoph Lameter wrote:
> On Fri, 22 Sep 2006, Andi Kleen wrote:
>
> > On Friday 22 September 2006 06:02, Christoph Lameter wrote:
> > > We have repeatedly discussed the problems of devices having varying
> > > address range requirements for doing DMA.
> >
> > We already have such an API. dma_alloc_coherent(). Device drivers
> > are not supposed to mess with GFP_DMA* directly anymore for quite
> > some time.
>
> Device drivers need to be able to indicate ranges of addresses that may be
> different from ZONE_DMA. This is an attempt to come up with a future
> scheme that does no longer rely on device drivers referring to zoies.
We already have that scheme. Any existing driver should be already converted
away from GFP_DMA towards dma_*/pci_*. dma_* knows all the magic
how to get memory for the various ranges. No need to mess up the
main allocator.
Anyways, i suppose what could be added as a fallback would be a
really_slow_brute_force_try_to_get_something_in_this_range() allocator
that basically goes through the buddy lists freeing in >O(1)
and does some directed reclaim, but that would likely be a separate
path anyways and not need your new structure to impact the O(1)
allocator.
I am still unconvinced of the real need. The only gaping hole was
GFP_DMA32, which we fixed already.
Ok there is aacraid with its weird 2GB limit, but in case there are
really enough users running into this broken then then the really_slow_*
thing above would be likely fine. And those cards are slowly going
away too.
If we managed to resist for too long now is the wrong time.
> > I actually have my doubts it is a good idea to add that now. The devices
> > with weird requirements are steadily going away
> Hmm.... Martin?
Think of it this way: all the weird slow devices of 5-10 years ago have USB
interfaces today and that does 32bit just fine (=GFP_DMA32). And old 5-10 years old weird
devices are usually fine with 16MB of playground only.
Ok now I'm sure someone will come up with a counter example (hi Alan), but:
- Does the device really need more than 16MB?
- How often is it used on systems with >1/2GB with a 64bit kernel?
[consider that 64bit kernels don't support ISA]
- How many users of that particular thing around?
I think my point stands.
-And
--
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 19:11 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 [this message]
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
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=200609222110.25118.ak@suse.de \
--to=ak@suse.de \
--cc=James.Bottomley@steeleye.com \
--cc=akpm@google.com \
--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.