From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25525 invoked by alias); 3 Dec 2013 15:36:44 -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 25516 invoked by uid 89); 3 Dec 2013 15:36:44 -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,URIBL_BLOCKED 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 15:36:42 +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 1Vns1Y-0007bC-H2 for ecos-discuss@ecos.sourceware.org; Tue, 03 Dec 2013 16:36:32 +0100 Received: from Groupware (Groupware.ITK [192.168.128.11]) by Groupware.ITK (Postfix) with ESMTP id BF7B92F9C5 for ; Tue, 3 Dec 2013 16:36:31 +0100 (CET) Received: from ITK-MTA by Groupware with Novell_GroupWise; Tue, 03 Dec 2013 16:36:31 +0100 Message-Id: <529E088D0200007E0000ABE5@Groupware> Date: Tue, 03 Dec 2013 15:36:00 -0000 From: "Peter Graf" To: "ecos-discuss@ecos.sourceware.org" References: <529DBE350200007E0000ABD9@Groupware> In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-IsSubscribed: yes Subject: Antw: RE: [ECOS] Massive ISR to DSR delay caused by free() X-SW-Source: 2013-12/txt/msg00002.txt.bz2 Thanks Bernd, I already tried the latest dlmalloc.cxx earlier, but apparently the simple = variable block implementation is used. Do you know in general, wether a DSR= gets delayed if free() is called from a thread? Kind regards, Peter >>> Bernd Edlinger schrieb am Dienstag, 3. Deze= mber 2013 um 14:37 in Nachricht : > On Tue, 3 Dec 2013 11:19:17, Peter Graf wrote: >> >> Hi, >> >> under rare circumstances, we experienced a massive timing overflow of a= =20 > cyclical DSR. It turned out to be an issue with JFFS2, occurring after a= =20 > 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=20 > was delayed, just because free() was called by jffs2_free_full_dnode(). M= ore=20 > 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= =20 > 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=20 > to free() from even a low priority thread seems to delay DSR execution af= ter=20 > the ISR! >> >> The allocator is compiled to be thread-safe, but in my opinion it would = be a=20 > major drawback if even a low priority thread could not call free() withou= t=20 > 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= =20 >> and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss= =20 >> >=20 > This sounds like a know deficiency of the very first Doug-Lee Malloc. >=20 > Maybe you want check if this patch works for you? >=20 > http://bugs.ecos.sourceware.org/show_bug.cgi?id=3D1001634=20 >=20 >=20 > Regards > Bernd Edlinger.=20=09=09=20=09=20=20=20=09=09=20=20 > -- > Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos= =20 > and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss =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