On Tue, 3 Dec 2013 11:19:17, Peter Graf wrote: > > Hi, > > under rare circumstances, we experienced a massive timing overflow of a > cyclical DSR. It turned out to be an issue with JFFS2, occurring after a > system reboot if long files had been written to the filesystem before. > > I found that the issue was only caused by JFFS2's > > malloc-ecos.c: jffs2_free_full_dnode() > > By using an oscilloscope, I could see that after the ISR was served, the DSR > was delayed, just because free() was called by jffs2_free_full_dnode(). More > precisely, the CPU time was spent in memalloc's > > mvarimpl.inl: Cyg_Mempool_Variable_Implementation::insert_free_block() > > At first I thought it was a locking issue within JFFS2. But in the end I > could not see any scheduler locks which might have caused it. > > I now have indications, that it could be a general issue with free(). A call > to free() from even a low priority thread seems to delay DSR execution after > the ISR! > > The allocator is compiled to be thread-safe, but in my opinion it would be a > major drawback if even a low priority thread could not call free() without > delaying a critical DSR. > > Can someone confirm this behaviour? Is it intended? > > Many thanks, > Peter > > > > > -- > Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos > and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss >
This sounds like a know deficiency of the very first Doug-Lee Malloc. Maybe you want check if this patch works for you? http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001634 Regards Bernd Edlinger. -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
