From: Gerd Knorr <kraxel@suse.de>
To: Ian Pratt <m+Ian.Pratt@cl.cam.ac.uk>
Cc: xen-devel@lists.xensource.com, Scott Parish <srparish@us.ibm.com>
Subject: Re: Xen 3.0 Status update
Date: 29 Jul 2005 11:06:22 +0200 [thread overview]
Message-ID: <871x5iasmp.fsf@bytesex.org> (raw)
In-Reply-To: <A95E2296287EAD4EB592B5DEEFCE0E9D28282C@liverpoolst.ad.cl.cam.ac.uk>
"Ian Pratt" <m+Ian.Pratt@cl.cam.ac.uk> writes:
> > Unfortunately, there still seems to be some places where
> > kmallocs are done for dma buffers. (i tried putting all linux
> > memory into ZONE_NORMAL and caught a couple of these places)
>
> Can you give examples? What size are the allocations? Do you know what
> the official position is i.e. is using kmalloc with ZONE_DMA deprecated?
If you do this:
fd = open("/dev/video0"); // open bttv grabber card
ioctl(fd, ...); // configure tvnorm, size, ...
read(fd, somelargebuf); // capture a single frame
bttv will try to send the video frame directly to the buffer passed.
Lock pages, kick DMA, wait until finished, unlock pages, done. And
bttv has no control at all about how these pages are allocated.
DMA memory really can be almost anything. There is no way around
having a swiotlb-like bounce buffer mechanism hooked into the dma
mapping API as fallback.
At the moment the linux kernel provides no way to hint that you want
to use the specific piece of memory you are asking for for 32-bit PCI
DMA. ZONE_DMA is historical stuff, 16MB only for ISA DMA IIRC, not
really useful. Maybe Andy finally finds some time to polish & submit
the ZONE_DMA32 patch.
bttv tries to allocate buffers from ZONE_NORMAL (i.e. avoid highmem)
in case it has control over the allocations, which is far from being
perfect. Works reliable only on 32 bit, doesn't work on 64-bit
without iommu and >4GB for example ...
Gerd
--
panic("it works"); /* avoid being flooded with debug messages */
next prev parent reply other threads:[~2005-07-29 9:06 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-07-28 23:05 Xen 3.0 Status update Ian Pratt
2005-07-28 21:59 ` Scott Parish
2005-07-29 9:06 ` Gerd Knorr [this message]
2005-07-29 10:17 ` Keir Fraser
-- strict thread matches above, loose matches on Subject: below --
2005-07-29 11:16 Ian Pratt
2005-07-29 12:58 ` Gerd Knorr
2005-07-28 23:31 Ian Pratt
2005-07-28 22:39 Ian Pratt
2005-07-28 21:43 ` Scott Parish
2005-07-28 22:57 ` Mark Williamson
2005-07-28 21:55 ` Scott Parish
2005-07-28 21:35 Ian Pratt
2005-07-28 20:30 ` Scott Parish
2005-07-28 21:15 Ian Pratt
2005-07-28 20:09 ` Scott Parish
2005-07-28 21:01 Walker, Bruce J (HP-Labs)
2005-07-28 11:52 Ian Pratt
2005-07-29 2:30 ` aq
2005-07-27 23:34 Ian Pratt
2005-07-28 4:28 ` aq
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=871x5iasmp.fsf@bytesex.org \
--to=kraxel@suse.de \
--cc=m+Ian.Pratt@cl.cam.ac.uk \
--cc=srparish@us.ibm.com \
--cc=xen-devel@lists.xensource.com \
/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.