All of lore.kernel.org
 help / color / mirror / Atom feed
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




  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.