[prev in list] [next in list] [prev in thread] [next in thread]
List: mjpeg-developer
Subject: Re: [Mjpeg-developer] Buffer management in the zr36067 driver
From: "Ronald S. Bultje" <rbultje () ronald ! bitfreak ! net>
Date: 2007-06-09 19:16:21
Message-ID: 34539a480706091216s5a1b8fd0vac0dcbc3b54805ae () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
Hi,
On 6/9/07, Jean Delvare <khali@linux-fr.org> wrote:
>
> The xfs code uses a 128 kB limit, too. From LDD3, about kmalloc:
> "If your code is to be completely portable, it cannot count on being
> able to allocate anything larger than 128 KB."
_If hardcoded_.
The maximum order seems to be 10 on x86_64. This is 4 MB. Even if we
> can't get that, being able to get 512 kB or 1 MB would be a significant
> improvement over the current situation. Maybe we can even get 2 or 4 MB
> if we preallocate the buffers on driver load. Arguably, this can be
> seen as a waste of kernel memory, so maybe this should be an option
> rather than the default.
[..]
> I believe that the driver should not hard-code a memory limit value.
> Instead, it should always try kmalloc (or __get_free_pages), and it
> should fallback to other methods (get_high_mem, bigphys_area) only if
> kmalloc fails. What do you think?
>
[..]
> Without CONFIG_BIGPHYS_AREA (default), the driver uses get_high_mem()
> to allocate large buffers, which looks like a gross, totally unsafe
> hack to me. And it doesn't work for me at least, the largest amount I
> manage to get is 32 kB. Does this really work for anyone? I'm surprised
> it was even accepted into the kernel tree. Shouldn't we remove this
> from the driver?
All yes.
Other v4l drivers (bttv, cx88) use a helper module called video-buf.
> The header comment says it implements non-contiguous, PCI-DMA-able
> buffers for video drivers. Couldn't this be used in the zr36067 driver
> as well?
No, it's non-contiguous, and thus useless for us. The whole base design is
around that, unfortunately.
Ronald
[Attachment #5 (text/html)]
Hi,<br><br><div><span class="gmail_quote">On 6/9/07, <b class="gmail_sendername">Jean \
Delvare</b> <<a href="mailto:khali@linux-fr.org">khali@linux-fr.org</a>> \
wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, \
204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> The xfs code uses a 128 kB \
limit, too. From LDD3, about kmalloc:<br>"If your code is to be completely \
portable, it cannot count on being<br>able to allocate anything larger than 128 \
KB."</blockquote><div><br>_If hardcoded_. <br></div><br><blockquote \
class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt \
0pt 0.8ex; padding-left: 1ex;">The maximum order seems to be 10 on x86_64. This is 4 \
MB. Even if we<br>can't get that, being able to get 512 kB or 1 MB would be a \
significant <br>improvement over the current situation. Maybe we can even get 2 or 4 \
MB<br>if we preallocate the buffers on driver load. Arguably, this can be<br>seen as \
a waste of kernel memory, so maybe this should be an option<br> rather than the \
default.</blockquote><div>[..]<br></div><blockquote class="gmail_quote" \
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; \
padding-left: 1ex;">I believe that the driver should not hard-code a memory limit \
value. <br>Instead, it should always try kmalloc (or __get_free_pages), and \
it<br>should fallback to other methods (get_high_mem, bigphys_area) only \
if<br>kmalloc fails. What do you think?<br></blockquote><div>[..] \
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, \
204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Without CONFIG_BIGPHYS_AREA \
(default), the driver uses get_high_mem()<br>to allocate large buffers, which looks \
like a gross, totally unsafe<br>hack to me. And it doesn't work for me at least, \
the largest amount I<br> manage to get is 32 kB. Does this really work for anyone? \
I'm surprised<br>it was even accepted into the kernel tree. Shouldn't we \
remove this<br>from the driver?</blockquote><div><br>All yes. \
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, \
204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Other v4l drivers (bttv, \
cx88) use a helper module called video-buf.<br>The header comment says it implements \
non-contiguous, PCI-DMA-able<br>buffers for video drivers. Couldn't this be used \
in the zr36067 driver<br>as well? </blockquote><div><br>No, it's non-contiguous, \
and thus useless for us. The whole base design is around that, \
unfortunately.<br><br>Ronald<br></div><br></div><br>
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Mjpeg-developer mailing list
Mjpeg-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-developer
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic