From: Stevie-O <oliver@klozoff.com>
To: Petr Vandrovec <VANDROVE@vc.cvut.cz>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Aliasing physical memory using virtual memory (from a d
Date: Wed, 17 Sep 2003 20:40:12 -0400 [thread overview]
Message-ID: <3F68FEEC.5020809@klozoff.com> (raw)
In-Reply-To: <80BC15566D@vcnet.vc.cvut.cz>
Petr Vandrovec wrote:
> On 17 Sep 03 at 19:36, Stevie-O wrote:
>
>>My thinking is this: I want to use __get_free_pages(1) 80 times to get the
>>160 pages, then passed those 80 pieces to the card (it's known the card can
>>handle requests with that many pieces). Then I want to create a *virtually*
>>contiguous 160-page mapping, so the postprocessing code in the driver can
>>view the 80 2-page sub-buffers as one big consecutive 160-page buffer.
>>Doing this would (a) make for more efficient use of memory, and (b) leave
>>the larger piles of contiguous pages to the drivers of cards that actually
>>require them.
>
>
> If you'll use __get_free_pages(0) 160 times, you should be able to use
> vmap() in 2.[456].x.
Actually, I specified __get_free_pages(1) 80 times because I don't know if the
card's SG can actually support 160 separate buffers (I'm certain it can do at
least 80 though).
I grepped my 2.4 kernel source for 'vmap' and the only results that seemed
meaningful were vmap_pte_range or vmap_pmd_range in mips/mm/umap.c and
mips64/mm/umap.c. Is this documented somewhere? I suffer from the 'i'm new at
this, but this looks possible' syndrome. I don't actually know how anything is
accomplished.
Btw, am I right about kmalloc(35000) effectively grabbing 64K?
>
> I must say that I do not understand why it checks for
> size > (max_mapnr << PAGE_SHIFT) in 2.4.x, or for count > num_physpages
> in 2.6.x (as there is nothing wrong with mapping same page several
> thousand times, or is it bad? with 32MB host you have plenty of
> unused VA space in the kernel...), but it should not hurt you as you
> need distinct physical pages.
>
> On other side, maybe that using SG even for driver operations is not
> that complicated. Do not forget that on bigmem boxes you have only
> 128MB area for vmalloc/vmap/ioremap, so you can quickly find that
> there is not 640KB continuous area available.
--
- Stevie-O
Real Programmers use COPY CON PROGRAM.EXE
next prev parent reply other threads:[~2003-09-18 0:43 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-09-18 0:19 Aliasing physical memory using virtual memory (from a d Petr Vandrovec
2003-09-18 0:40 ` Stevie-O [this message]
2003-09-18 1:10 ` Stevie-O
2003-09-18 10:32 ` Petr Vandrovec
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=3F68FEEC.5020809@klozoff.com \
--to=oliver@klozoff.com \
--cc=VANDROVE@vc.cvut.cz \
--cc=linux-kernel@vger.kernel.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 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.