From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13641 invoked from network); 19 Oct 2004 22:42:45 +0000 Received: from smtp.gentoo.org (156.56.111.197) by lists.gentoo.org with AES256-SHA encrypted SMTP; 19 Oct 2004 22:42:46 +0000 Received: from lists.gentoo.org ([156.56.111.196] helo=parrot.gentoo.org) by smtp.gentoo.org with esmtp (Exim 4.41) id 1CK2gn-0004MB-M7 for arch-gentoo-dev@lists.gentoo.org; Tue, 19 Oct 2004 22:42:45 +0000 Received: (qmail 30977 invoked by uid 89); 19 Oct 2004 22:42:45 +0000 Mailing-List: contact gentoo-dev-help@gentoo.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Received: (qmail 28585 invoked from network); 19 Oct 2004 22:42:44 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Date: Tue, 19 Oct 2004 15:42:40 -0700 Organization: Sometimes Message-ID: References: <200410191926.13381.danarmak@gentoo.org> <200410192040.54826.danarmak@gentoo.org> <200410192203.49686.danarmak@gentoo.org> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1250 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: ip68-230-66-58.ph.ph.cox.net User-Agent: Pan/0.14.2.91 (As She Crawled Across the Table) Sender: news Subject: [gentoo-dev] Re: Re: ANN: broken-up kde ebuilds (aka 'emerge kmail') X-Archives-Salt: 3b152bdc-19ae-4f10-b292-ac3e7067d9c7 X-Archives-Hash: 4b511159b9e471d1faec17a6fd709fa9 Dan Armak posted <200410192203.49686.danarmak@gentoo.org>, excerpted below, on Tue, 19 Oct 2004 22:03:41 +0200: >> From earlier, I remember you (?) saying what it DID cache, it >> invalidated entirely if there was just one change. I can see how this >> would be simpler to implement. However, if you are caching everything, >> I'd hope you are doing it in segments > > Caching is a builtin feature of configure scripts generated by autoconf. > configure --help | grep cache will show you. All we do in confcache is > store the cache after every run and give it to the next run. Ahh... I'd seen occasional (cached) entries in the various "checking ..." messages. This now makes sense. > So we have to invalidate it entirely and we can't segment it. Either > behaviour would require basically replacing/rewriting autoconf. And if > someone did do that, I'd be very happy :-) (Maybe the unsermake people?) > But for now, this is all we can do. Aye... that /does/ sound like an unsermake project. > That said if the existing bugs are worked out (like not panicking when > /proc/cpuinfo's checksum changes due to cpu clock changes) our confcache > is pretty good too in terms of performance. Ugly! Is the cache kept in such a way that for specific things like this, one can go in and excise them using sed and the like? That would seem the best solution if so. Simply make it as if the cpuinfo stuff hadn't been cached, yet, so it'd test for it each time new. Or.. perhaps even better, intercept the call for the cpuinfo checksum and return the existing checksum, or the existing data, whichever is easier, so it doesn't see it as changed. Of course there'd have to be a way to manually trigger a real check, say, if the CPU was replaced or whatever. In another discussion, on the AMD64 list, we were talking about how ultimately, power management for multiple CPUs might be accomplished by using the developing CPU hotplug code to turn off one CPU at a time until only one was left, then speed throttling the one CPU. (I've seen kernel discussion on using the hotplug code for suspend, tho not specifically for power management not suspend, however, it's a logical extension, if they are already talking about extending it to suspend, to use it for throttling as well, given that existing throttling power management doesn't work at all with multiple CPUs.) If speed throttling throws a wrench in the current system, consider what hotplugging CPUs will do to it as well! Perhaps whatever solution is found for the first can address the second, when the time comes too, if it's planned for in advance. -- Duncan - List replies preferred. No HTML msgs. "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." -- Benjamin Franklin -- gentoo-dev@gentoo.org mailing list