From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2123 invoked by alias); 17 Jan 2004 01:51:12 -0000 Mailing-List: contact libc-hacker-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-hacker-owner@sources.redhat.com Received: (qmail 2071 invoked from network); 17 Jan 2004 01:51:12 -0000 Received: from unknown (HELO palrel12.hp.com) (156.153.255.237) by sources.redhat.com with SMTP; 17 Jan 2004 01:51:12 -0000 Received: from hplms2.hpl.hp.com (hplms2.hpl.hp.com [15.0.152.33]) by palrel12.hp.com (Postfix) with ESMTP id 50B1F1C0132C; Fri, 16 Jan 2004 17:51:12 -0800 (PST) Received: from napali.hpl.hp.com (napali.hpl.hp.com [15.4.89.123]) by hplms2.hpl.hp.com (8.12.10/8.12.10/HPL-PA Hub) with ESMTP id i0H1pBjQ024049; Fri, 16 Jan 2004 17:51:11 -0800 (PST) Received: from napali.hpl.hp.com (napali [127.0.0.1]) by napali.hpl.hp.com (8.12.9/8.12.9/Debian-5) with ESMTP id i0H1pBVR007326; Fri, 16 Jan 2004 17:51:11 -0800 Received: (from davidm@localhost) by napali.hpl.hp.com (8.12.9/8.12.9/Debian-5) id i0H1pAwZ007322; Fri, 16 Jan 2004 17:51:10 -0800 From: David Mosberger MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16392.38158.910091.724717@napali.hpl.hp.com> Date: Sat, 17 Jan 2004 01:51:00 -0000 To: Jakub Jelinek Cc: Roland McGrath , davidm@hpl.hp.com, GNU libc hackers Subject: Re: enabling caching for dl_iterate_phdr() In-Reply-To: <20040116232931.GL6413@sunsite.ms.mff.cuni.cz> References: <16387.9755.753294.37588@napali.hpl.hp.com> <200401170057.i0H0vQag022225@magilla.sf.frob.com> <20040116232931.GL6413@sunsite.ms.mff.cuni.cz> Reply-To: davidm@hpl.hp.com X-URL: http://www.hpl.hp.com/personal/David_Mosberger/ X-SW-Source: 2004-01/txt/msg00066.txt.bz2 >>>>> On Sat, 17 Jan 2004 00:29:31 +0100, Jakub Jelinek said: Jakub> On Fri, Jan 16, 2004 at 04:57:26PM -0800, Roland McGrath wrote: >> > In any case, if a callback-based approach is preferred, I can live >> > with that, too. >> I don't claim it's the best interface. But that is the approach that >> doesn't have other blocking issues right now. Jakub> How about extending struct dl_phdr_info and passing an counter in it Jakub> to dl_iterate_phdr's callback? Jakub> The structure can be extended at the end, because dl_iterate_phdr Jakub> passes its size to the callback as well. Jakub> The callback is called with dl_load_lock held, so the counter doesn't Jakub> even have to be atomic. Jakub> libgcc_s would just see if size includes the additional field in the Jakub> first callback, if yes, it would record that counter and on subsequent Jakub> dl_iterate_phdr call it would first check whether the counter did not Jakub> change and if it is the same, it could use cached info. Sounds good to me. I assume it'd be OK to have separate "additions" and "removals" counters? Only the latter is needed for avoiding stale values in a cache, but the former helps performance, because dl_iterate_phdr() can be stopped early if we know that the list didn't change. I'd be happy to prototype the necessary code, but at the moment, glibc doesn't build for me on ia64 (it crashes in rpcgen). I assume that's due to the stuff Uli is working on. --david