Actually this should only matter for dma buffers on kernel side and
for userspace not at all. A region of continous virtual memory can
consists of physically scattered memory without problems. That's what
the page table is for.
Bernhard
2010/3/10 Fabrizio Bertocci <fabrizioberto...@gmail.com>:
> Well,
> Im not an expert of the kernel, but if I remember correctly, when the
> system runs low in memory, the kernel doesn't necessarily kill the
> process with higher memory use... and if fragmentation is really the
> problem, the mjpg-streamer may have very little memory allocated
> anyway...
> I've seen those kind of behavior on 2.4 kernels...
>
> Going back to the mjpg-streamer, if the mjpg-streamer is designed to
> do a malloc...free for every processed frame, I'm sure that is the
> possible cause of your problem. Eventually the memory has a lot of
> holes here and there, and there is not a single block that is large
> enough to accommodate a new request.
>
> If you can modify the code (I'm not familiar with mjpg-streamer), you
> should review the memory allocation policy, and use for example a fast
> buffer pool that preallocate a chunk of memory at startup and never
> call free anymore... then you can manage this memory by yourself in a
> more optimized way (i.e. get a buffer of the same size from this
> pool).
>
> Well, hopefully somebody else with more experience with the kernel can
> give you more hints about the kernel problem.
>
> Fab
>
>
> 2010/3/10 Kövesdi György <k...@teledigit.hu>:
>>> Although there is still enough free memory, probably the memory is
>>> entirely fragmented and it cannot allocate a large block?
>> What size of block does it need? I think it cannot be larger than one file
>> (~30...80k). I cannot imagine that it cannot be allocated. Or, if it occures,
>> only the mjpg-streamer is killed. In my case, _all_ processes are killed,
>> that's why I think there can be a bug somewhere in the kernel. (in the UVC
>> driver?)
>>
>>> Does this problem occur regularly after about 300k frames?
>> I tried with different resolution and speed, it is within 290k...310k frames.
>>
>>> In this case why don't you try to stop and restart mjpg-streamer right
>>> before that just to see if the system stays up for a longer time?
>> I will try it, but I would like to catch the problem in the kernel.
>> Unfortunately, I don't know too much about the memory handling within the
>> kernel. At least the source is available (it is my own compilation), so I
>> will
>> try to do something. Any help would be appreciated.
>>
>> Thanx
>> K. Gy.
>> _______________________________________________
>> openwrt-devel mailing list
>> openwrt-devel@lists.openwrt.org
>> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
>>
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
>
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
