Hi Mauro,
On Thursday 06 May 2010 15:23:10 Mauro Carvalho Chehab wrote:
> Laurent Pinchart wrote:
> > On Thursday 06 May 2010 14:38:36 Mauro Carvalho Chehab wrote:
> >> Laurent Pinchart wrote:
> >>> On Thursday 06 May 2010 01:29:54 Aguirre, Sergio wrote:
> >>>>> -----Original Message-----
> >>>>> From: Mauro Carvalho Chehab [mailto:[email protected]]
> >>>>> Sent: Wednesday, May 05, 2010 6:24 PM
> >>>>> To: Aguirre, Sergio
> >>>>> Cc: [email protected]
> >>>>> Subject: Re: [videobuf] Query: Condition bytesize limit in
> >>>>> videobuf_reqbufs -> buf_setup() call?
[snip]
> >>>>> I don't see any problem on propagating the memory type to
> >>>>> buffer_setup, if this is really needed. Yet, I can't see why you
> >>>>> would restrict the buffer size to 32 MB on one case, and not
> >>>>> restrict the size at all with non-MMAP types.
> >>>>
> >>>> Ok, my reason for doing that is because I thought that there should be
> >>>> a memory limit in whichever place you're doing the buffer
> >>>> allocations.
> >>>>
> >>>> MMAP is allocating buffers in kernel, so kernel should provide a
> >>>> memory restriction, if applies.
> >>>>
> >>>> USERPTR is allocating buffers in userspace, so userspace should
> >>>> provide a memory restriction, if applies.
> >>>
> >>> I agree with the intend here, but not with the current implementation
> >>> which has a hardcoded arbitrary limit. Do you think it would be
> >>> possible to compute a meaningful default limit in the V4L2 core, with
> >>> a way for userspace to modify it (with root privileges of course) ?
> >>
> >> On almost all drivers, the limit is not arbitrary. It is a reasonable
> >> number of buffers (like 16 buffers). A limit in terms of the number of
> >> buffers is meaningful for V4L2 API, and also, has a "physical meaning":
> >> considering that almost all drivers that use videobuf can do at maximum
> >> 30 fps, 16 buffers mean that the maximum delay that the driver will
> >> apply to the stream is 533 ms.
> >>
> >> Some drivers even provide a modprobe parameter to allow changing this
> >> limit (for example, bttv allows changing it up to 32 buffers), but only
> >> during module load time. I can't foresee any use case where this
> >> maximum limit would need to be dynamically adjusted. Root can always
> >> change it by removing and re-inserting the module with a new maximum
> >> size.
> >
> > I wasn't talking about the limit on the number of buffers, but on the
> > amount of memory. That's what Sergio was mentioning, and that's what is
> > done in the OMAP3 ISP driver.
>
> The memory consumption is basically dictated by the maximum size of an
> image (resolution x bpp / 8) and the number of buffers. An arbitrary value
> in terms of megabytes is meaningless: it is just a random number above
> some reasonable limit.
>
> The proper way to limit memory is to do something like:
>
> #define MAX_HRES 1920
> #define MAX_VRES 1650
> #define MAX_DEPTH 3
> #define MAX_BUFS 4
>
> #define MAX_MEMSIZE (MAX_HRES * MAX_VRES * MAX_DEPTH * MAX_BUFS)
>
> buf_setup(...)
> {
> if (size > MAX_MEMSIZE)
> fix_it_by_reducing_number_of_buffers();
> }
That's what we do. The limit is this not a number of buffers, but a memory
limit. You an allocate more than 4 buffers in small resolutions. This is still
a somewhat arbitrary limit. The OMAP3 ISP driver has 7 video nodes (a 8th one
is possible). If we let userspace application allocate 3 buffers of the
maximum size (think about 4096x4096 and 2 bytes per pixel, could be even
higher for some of the blocks), the total is 256MB. That's quite a lot. A
device-global memory limit might need to be enforced.
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
