From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 26 21:06:22 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 55F8016A4CE for ; Wed, 26 Jan 2005 21:06:22 +0000 (GMT) Received: from mhultra.aero.org (mhultra.aero.org [130.221.88.102]) by mx1.FreeBSD.org (Postfix) with ESMTP id D28CE43D45 for ; Wed, 26 Jan 2005 21:06:21 +0000 (GMT) (envelope-from cal@rushg.aero.org) Received: from rushe.aero.org ([130.221.24.10] [130.221.24.10]) by mhultra.aero.org with ESMTP; Wed, 26 Jan 2005 13:06:20 -0800 Received: from calamari.aero.org (calamari.aero.org [130.221.26.26]) by rushe.aero.org (8.11.7p1+Sun/8.11.7) with ESMTP id j0QL6Jj08722; Wed, 26 Jan 2005 13:06:20 -0800 (PST) Received: from calamari.aero.org (localhost [127.0.0.1]) by calamari.aero.org (8.12.11/8.11.6) with ESMTP id j0QL5xKA042385; Wed, 26 Jan 2005 13:05:59 -0800 (PST) (envelope-from cal@calamari.aero.org) Received: (from cal@localhost) by calamari.aero.org (8.12.11/8.12.11/Submit) id j0QL5x9W042384; Wed, 26 Jan 2005 13:05:59 -0800 (PST) (envelope-from cal) Date: Wed, 26 Jan 2005 13:05:59 -0800 (PST) From: Chris Landauer Message-Id: <200501262105.j0QL5x9W042384@calamari.aero.org> To: ambrisko@ambrisko.com X-Mailman-Approved-At: Thu, 27 Jan 2005 13:29:52 +0000 cc: freebsd-hackers@freebsd.org cc: cal@rush.aero.org Subject: Re: bug in calcru() X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2005 21:06:22 -0000 hihi, doug - > Doug Ambrisko wrote > ... > The assumption with this calculation is that st & it tend to be > small compared to tt so the 1024 X shouldn't overflow much. > ... > cal@aero.org wrote: > | ...but i'm a little worried that the 1024 multiplications aren't > | large enough when tt gets really large > | > Doug Ambrisko wrote > | > ... > | > /* Subdivide tu. try to becareful of overflow */ > | > su = tu * (st * 1024 / tt) / 1024; > | > iu = tu * (it * 1024 / tt) / 1024; > | > uu = tu - (su + iu); > | > ... i'm not so worried about the overflow limit (that's what the mathematical analysis is intended to discover, and i assume that the bound is large enough to ignore the issue - that is the really clever part about computing su and iu first instead of uu), but the underflow - if st and it are small enough and tt is large enough, these equations produce 0 for both su and iu (and the reported percentage will rightly be 0.00%, but i want to see the rest of the detail for my time models) what i think i'll do is try out my set of if-protected equations, but with your choice of computing su and iu - that ought to avoid both problems #define TOOBIG 45254834 /* 32*sqrt(2)*10^6 */ if (tt >= TOOBIG && tu >= tt) { u_int64_t q, r; q = tu / tt; r = tu % tt; su = (q * st) + (r * st) / tt; iu = (q * it) + (r * it) / tt; } else { su = (tu * st) / tt; iu = (tu * it) / tt; } uu = tu - (su + iu); of course, JUST using the lines su = (tu * st) / tt; iu = (tu * it) / tt; uu = tu - (su + iu); will help a lot already - perhaps this much should be done right now (according to the usual committment protocols) while we analyze the various alternative suggestions for improvement (or are there high-utilization processes that are more system time than user time?) general question - is it (interrupt time) where the unreported time is when user and system percentages add up to much less than 100%? i assume that the monotonicity rules are what makes programs report over 100% utilization (which i get occasionally, but only on very short programs) more later, cal Chris Landauer Aerospace Integration Science Center The Aerospace Corporation cal@aero.org PS - i'm sorry i don't speak "patch" well enough yet, but i will eventually