From: Mike Galbraith <EFAULT@gmx.de>
To: Roland Kuhn <rkuhn@e18.physik.tu-muenchen.de>
Cc: Bhavana Nagendra <Bhavana.Nagendra@3dlabs.com>,
Gilad Ben-Yossef <gilad@benyossef.com>,
linux-kernel@vger.kernel.org
Subject: Re: Alloc and lock down large amounts of memory
Date: Wed, 21 Aug 2002 16:35:57 +0200 [thread overview]
Message-ID: <3D63A54D.8010902@gmx.de> (raw)
In-Reply-To: Pine.LNX.4.44.0208211528180.3407-100000@pc40.e18.physik.tu-muenchen.de
Roland Kuhn wrote:
>On Wed, 21 Aug 2002, Mike Galbraith wrote:
>
>>At 03:08 PM 8/20/2002 -0500, Bhavana Nagendra wrote:
>>
>>>>Curiosity: why do you want to do device DMA buffer
>>>>allocation from userland?
>>>>
>>>I need 256M memory for a graphics operation. It's a requiremment,
>>>can't change it. There will be other reasonably sized allocs in kernel
>>>space, this is a special case that will be done from userland. As
>>>discussed earlier in this thread, there's no good way of alloc()ing
>>>and pinning that much in DMA memory space, is there?
>>>
>>Not that I know of. It seems to me that any interface that tried
>>to provide this would have to know what kind of device is going
>>to DMA from/to that ram.
>>
>>Usually, when someone needs a large gob of contiguous ram,
>>folks suggest doing the allocation in kernel, and early.
>>
>BTW: What is the limit for pci_alloc_consistent and friends? Can it really
>provide 256MB?
>
Dunno. The page allocator however (lowest) can deliver 1 << MAX_ORDER
contiguous
pages per request.. unless fragmentation gets you that is, so I doubt
it's remotely possible
to get 256MB of _physically_ contiguous ram without doing early
allocation of some sort.
(bootmem, bigphysarea patches or whatnot)
-Mike
next prev parent reply other threads:[~2002-08-21 14:35 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <23B25974812ED411B48200D0B774071701248C6A@exchusa03.intense 3d.com>
2002-08-21 4:31 ` Alloc and lock down large amounts of memory Mike Galbraith
2002-08-21 13:29 ` Roland Kuhn
2002-08-21 14:35 ` Mike Galbraith [this message]
2002-08-20 20:08 Bhavana Nagendra
2002-08-20 20:47 ` Richard B. Johnson
[not found] ` <Pine.LNX.3.95.1020820163301.27264A-100000@chaos.analogic.c om>
2002-08-21 4:43 ` Mike Galbraith
2002-08-21 5:29 ` Gilad Ben-Yossef
-- strict thread matches above, loose matches on Subject: below --
2002-08-20 14:51 Bhavana Nagendra
2002-08-21 5:27 ` Gilad Ben-Yossef
2002-08-16 14:38 Bhavana Nagendra
2002-08-18 12:09 ` Gilad Ben-Yossef
2002-08-18 12:18 ` Alan Cox
2002-08-18 22:45 ` Gilad Ben-Yossef
2002-08-18 12:19 ` Gilad Ben-Yossef
2002-08-19 12:06 ` Bhavana Nagendra
2002-08-20 5:38 ` Gilad Ben-Yossef
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=3D63A54D.8010902@gmx.de \
--to=efault@gmx.de \
--cc=Bhavana.Nagendra@3dlabs.com \
--cc=gilad@benyossef.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rkuhn@e18.physik.tu-muenchen.de \
/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.