From: "Petr Vandrovec" <VANDROVE@vc.cvut.cz>
Organization: CC CTU Prague
To: Stevie-O <oliver@klozoff.com>
Date: Thu, 18 Sep 2003 02:19:50 +0200
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: Aliasing physical memory using virtual memory (from a d
Cc: linux-kernel@vger.kernel.org
Message-ID: <80BC15566D@vcnet.vc.cvut.cz>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1753
Lines: 34

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.

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.
                                                    Best regards,
                                                        Petr Vandrovec
                                                        vandrove@vc.cvut.cz

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/