From: Eugene Surovegin <ebs@ebshome.net>
To: Laurent Lagrange <lagrange@fr.oleane.com>
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: MPC8260 strange virtual addresses returned by kmalloc()
Date: Thu, 6 Jan 2005 10:59:37 -0800 [thread overview]
Message-ID: <20050106185937.GC6539@gate.ebshome.net> (raw)
In-Reply-To: <000001c4f417$25e84260$5201a8c0@GEG2400>
On Thu, Jan 06, 2005 at 06:42:50PM +0100, Laurent Lagrange wrote:
> My PAGE_OFFSET is defined as follow :
> #define PAGE_OFFSET CONFIG_KERNEL_START in
> ./linux/include/asm-ppc/page.h
> #define CONFIG_KERNEL_START (0xc0000000) in
> ./linux/include/linux/autoconf.h
>
> After reading kmalloc manual pages, I am in doubt.
> My call is like
> if ((tmpbuffer = kmalloc(128 * 1024, GFP_KERNEL)) == NULL){
> return(1);
> }
>
> This is the first time, I kmallocate a 128KB buffer which seems to be the
> max
> contiguous memory space which can be allocated.
> Is it true on PPC ? Some PPC drivers seems to only allocate multiple
> PAGE_SIZE (4KB) buffers.
kmalloc implementation isn't PPC specific. It's the same code for
every arch.
Regardless, if kmalloc cannot allocate amount of memory you have
requested, it'll return NULL and you must handle this gracefully.
kmalloc _always_ allocate physically continuous pages. That's why
trying to allocate 128K is bad idea, because it's more likely to fail.
> My allocated buffer is intended to be used for DMA accesses.
> Must I add the GFP_DMA flag to force the kmalloc to use contiguous memory ?
You need to use this flag to get DMA memory, although on PPC usually
all RAM is available for DMA.
> > The Linux code for vmalloc is based on successive kmalloc calls, but I don't
> know
> what the kmalloc do when the desired size is greater than the PAGE_SIZE.
That's not correct. vmalloc uses kmalloc only to allocate vm_struct.
Actual memory is allocated using alloc_page and then this page is
mapped by installing PTE into the kernel page table.
> What is the right way to allocate big (128KB ???) DMA buffers ?
> The manual pages say "Only for DMA kmalloc or __get_dma_pages() has to be
> used"
Generally for PAGE_SIZE * n allocations it's more efficient to use
__get_free_pages and friends. But kmalloc should also be OK. The only
limitation is the maximum size of such allocations, but you already
know this.
> The global variable is well in the loaded module.
> OK, I use a kmalloc for the buffer instead of using the global variable.
Memory for DMA should always be allocated using specially designed
functions. Don't use stack or static storage unless you know what you
are doing :).
--
Eugene
prev parent reply other threads:[~2005-01-06 18:59 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-01-05 13:38 MPC8260 strange virtual addresses returned by kmalloc() Laurent Lagrange
2005-01-05 17:41 ` Eugene Surovegin
2005-01-06 17:42 ` Laurent Lagrange
2005-01-06 18:59 ` Eugene Surovegin [this message]
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=20050106185937.GC6539@gate.ebshome.net \
--to=ebs@ebshome.net \
--cc=lagrange@fr.oleane.com \
--cc=linuxppc-embedded@ozlabs.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).