From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 971 invoked by alias); 3 Dec 2013 10:19:30 -0000 Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Received: (qmail 960 invoked by uid 89); 3 Dec 2013 10:19:30 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=1.6 required=5.0 tests=BAYES_50,RDNS_NONE autolearn=no version=3.3.2 X-HELO: mail3.becom.net Received: from Unknown (HELO mail3.becom.net) (195.226.69.26) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Tue, 03 Dec 2013 10:19:29 +0000 Received: from p50992e59.dip0.t-ipconnect.de ([80.153.46.89] helo=Groupware.ITK) by mail3.becom.net with esmtpa (Exim 4.69) (envelope-from ) id 1Vnn4Z-0000v7-CW for ecos-discuss@ecos.sourceware.org; Tue, 03 Dec 2013 11:19:19 +0100 Received: from Groupware (Groupware.ITK [192.168.128.11]) by Groupware.ITK (Postfix) with ESMTP id A7BDE2F6C3 for ; Tue, 3 Dec 2013 11:19:18 +0100 (CET) Received: from ITK-MTA by Groupware with Novell_GroupWise; Tue, 03 Dec 2013 11:19:18 +0100 Message-Id: <529DBE350200007E0000ABD9@Groupware> Date: Tue, 03 Dec 2013 10:19:00 -0000 From: "Peter Graf" To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-IsSubscribed: yes Subject: [ECOS] Massive ISR to DSR delay caused by free() X-SW-Source: 2013-12/txt/msg00000.txt.bz2 Hi, under rare circumstances, we experienced a massive timing overflow of a cyc= lical DSR. It turned out to be an issue with JFFS2, occurring after a syste= m reboot if long files had been written to the filesystem before.=20 I found that the issue was only caused by JFFS2's=20 malloc-ecos.c: jffs2_free_full_dnode()=20 By using an oscilloscope, I could see that after the ISR was served, the DS= R was delayed, just because free() was called by jffs2_free_full_dnode(). = More precisely, the CPU time was spent in memalloc's=20 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 co= uld not see any scheduler locks which might have caused it. I now have indications, that it could be a general issue with free(). A cal= l to free() from even a low priority thread seems to delay DSR execution af= ter 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() withou= t delaying a critical DSR. Can someone confirm this behaviour? Is it intended? Many thanks, Peter =20 -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss