Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.os.linux.embedded > #547
| 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.
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 | Next — Previous in thread | Next in thread | Find similar | Unroll 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