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 <[email protected]>: >> 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 > [email protected] > https://lists.openwrt.org/mailman/listinfo/openwrt-devel > _______________________________________________ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
