Massive ISR to DSR delay caused by free()

"Peter Graf" <[email protected]>
Newsgroups gmane.os.ecos.general
Message-ID <529DBE350200007E0000ABD9@Groupware>
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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.