Re: [PATCH] video: mx3_camera: Allocate camera object via kzalloc

[Mauro Carvalho Chehab <mchehab@redhat.com>]

Em 20-03-2012 04:57, Guennadi Liakhovetski escreveu:
> On Mon, 19 Mar 2012, Mauro Carvalho Chehab wrote:
> 
>> Em 20-02-2012 16:23, Fabio Estevam escreveu:
>>> On Mon, Feb 20, 2012 at 4:17 PM, Guennadi Liakhovetski
>>> <g.liakhovetski@gmx.de> wrote:
>>>> On Mon, 20 Feb 2012, Fabio Estevam wrote:
>>>>
>>>>> Align mx3_camera driver with the other soc camera driver implementations
>>>>> by allocating the camera object via kzalloc.
>>>>
>>>> Sorry, any specific reason, why you think this "aligning" is so important?
>>>
>>> Not really.
>>>
>>> Just compared it with all other soc camera drivers I found and
>>> mx3_camera was the only one that uses "vzalloc"
>>>
>>> Any specific reason that requires mx3_camera to use "vzalloc" instead
>>> of "kzalloc"?
>>
>> kzalloc() is more restrictive than vzalloc(). With v*alloc, it will allocate
>> a virtual memory area, with can be discontinuous, while kzalloc will get
>> a continuous area.
>>
>> The DMA logic need to be prepared for virtual memory, if v*alloc() is used
>> (e. g. using videobuf2-vmalloc).
>>
>> As it is currently including media/videobuf2-dma-contig.h, I this patch
>> makes sense on my eyes.
> 
> Don't think so. vzalloc() is used in mx3_camera to allocate driver private 
> data objects and are never used for DMA, so, it doesn't have any 
> restrictions on contiguity, coherency, alignment etc.

OK. In this case, using v*alloc()/vfree() won't be that different than k*alloc()/k*free().

> One could argue, that since the struct is anyway smaller than 1 page, it 
> anyway will be allocated in a physically contiguous memory area (will it?) 
> and so, maybe, kmalloc() is less heavy weight than vmalloc() and might 
> save a couple of CPU cycles, but I don't think it's anything important, 
> that we should be optimising for.

Yes. 

There's another aspect to consider there: the vmalloc space is limited
(there's a boot time parameter to regulate its size)[1]. I dunno why, nor
what are the consequences of using a bigger value, but I think a big vmalloc
size creates a big table to map between virtual/physical memory space.

Yet, a single page is far below the vmaloc default max size,
except if the system has very severe memory constraints.

[1] On x86, I think that the default is 256MB. Several video adapters
eat a lot of space there. I use a bigger value here, otherwise my 3-head
system won't initialize all screens.

Regards,
Mauro