Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.os.linux.embedded > #547

Re: kmalloc()ing HUGE buffers in excess of 1Gb - bigphysarea alternatives?

From Les Cargill <lcargill99@comcast.com>
Newsgroups comp.arch.embedded, comp.os.linux.embedded
Subject Re: kmalloc()ing HUGE buffers in excess of 1Gb - bigphysarea alternatives?
Date 2013-10-20 18:19 -0500
Organization A noiseless patient Spider
Message-ID <l41o6b$f5t$1@dont-email.me> (permalink)
References <g2K8u.96599$gp1.58602@en-nntp-16.dc1.easynews.com> <l414p7$su6$1@dont-email.me> <DwX8u.11745$Lj7.10059@en-nntp-01.dc1.easynews.com>

Cross-posted to 2 groups.

Show all headers | View raw


jackbenimble wrote:
>> Use custom linker scripts to declare a peer memory section to .bss,
>> .data and the like. You'll have to declare the buffer in 'C' with
>> overrides for the section name to match what your linker script uses.
>
> Unfortunately this buffer would work for USER land programs but not for
> a dma controller.

I presume you're in a kernel module, so in that case, yes it would work
exactly as you'd expect - if it works at all.

> memory buffers/addresses passed to a dma controller must
> have certain properties:
>
> physically contiguous and page locked (non swappable) being the most
> important.
>
> Would your suggestion above satisfy that?


I would think it could be made to do so, but I haven't gone through the
exersize. I know it'd be contiguous, and since it would be allocated 
only to this device driver ( through a mechanism to be named later?
I am unsure if insmod takes care of that for you, but I woould think it 
would - it's the moral equivalent of "ld" ...  ).

SFAIK ), locking just accepts an address range:
int mlock(const void *addr, size_t len); I beleive you must be 
privileged to call mlock(), and I'm not sure what addr means in kernel 
space.

I am also unsure how to interface linker scripts and such through the 
device driver build process, which may or may not use the usual
tools in the same way.

> In my experience memory
> allocated by the os for processes are virtually contiguous and rarely
> physically so (malloc vs kmalloc).
>

Right. A peer section to .bss would be all one big hunk.

--
Les Cargill

Back to comp.os.linux.embedded | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

kmalloc()ing HUGE buffers in excess of 1Gb - bigphysarea alternatives? jackbenimble <jackbenimble@mindyourhusiness.com> - 2013-10-20 05:41 +0000
  Re: kmalloc()ing HUGE buffers in excess of 1Gb - bigphysarea alternatives? Tim Wescott <tim@seemywebsite.please> - 2013-10-20 10:43 -0500
    Re: kmalloc()ing HUGE buffers in excess of 1Gb - bigphysarea alternatives? jackbenimble <jackbenimble@mindyourhusiness.com> - 2013-10-20 22:14 +0000
  Re: kmalloc()ing HUGE buffers in excess of 1Gb - bigphysarea alternatives? Don Y <this@isnotme.com> - 2013-10-20 10:10 -0700
    Re: kmalloc()ing HUGE buffers in excess of 1Gb - bigphysarea alternatives? jackbenimble <jackbenimble@mindyourhusiness.com> - 2013-10-20 22:08 +0000
      Re: kmalloc()ing HUGE buffers in excess of 1Gb - bigphysarea alternatives? George Neuner <gneuner2@comcast.net> - 2013-10-21 03:33 -0400
    Re: kmalloc()ing HUGE buffers in excess of 1Gb - bigphysarea alternatives? upsidedown@downunder.com - 2013-10-21 09:04 +0300
  Re: kmalloc()ing HUGE buffers in excess of 1Gb - bigphysarea alternatives? Les Cargill <lcargill99@comcast.com> - 2013-10-20 12:48 -0500
    Re: kmalloc()ing HUGE buffers in excess of 1Gb - bigphysarea alternatives? jackbenimble <jackbenimble@mindyourhusiness.com> - 2013-10-20 21:01 +0000
      Re: kmalloc()ing HUGE buffers in excess of 1Gb - bigphysarea alternatives? Les Cargill <lcargill99@comcast.com> - 2013-10-20 18:19 -0500
    Re: kmalloc()ing HUGE buffers in excess of 1Gb - bigphysarea alternatives? Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2013-10-20 17:16 -0400

csiph-web