From owner-freebsd-arch@FreeBSD.ORG Tue May 29 21:18:40 2007 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 622D816A400; Tue, 29 May 2007 21:18:40 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from webaccess-cl.virtdom.com (webaccess-cl.virtdom.com [216.240.101.25]) by mx1.freebsd.org (Postfix) with ESMTP id 06E7713C45B; Tue, 29 May 2007 21:18:39 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from [192.168.1.101] (c-71-231-138-78.hsd1.or.comcast.net [71.231.138.78]) (authenticated bits=0) by webaccess-cl.virtdom.com (8.13.6/8.13.6) with ESMTP id l4TLIbPK009179 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Tue, 29 May 2007 17:18:38 -0400 (EDT) (envelope-from jroberson@chesapeake.net) Date: Tue, 29 May 2007 14:18:32 -0700 (PDT) From: Jeff Roberson X-X-Sender: jroberson@10.0.0.1 To: Bruce Evans In-Reply-To: <20070530065423.H93410@delplex.bde.org> Message-ID: <20070529141342.D661@10.0.0.1> References: <20070529105856.L661@10.0.0.1> <200705291456.38515.jhb@freebsd.org> <20070529121653.P661@10.0.0.1> <20070530065423.H93410@delplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-arch@freebsd.org Subject: Re: rusage breakdown and cpu limits. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2007 21:18:40 -0000 On Wed, 30 May 2007, Bruce Evans wrote: > On Tue, 29 May 2007, Jeff Roberson wrote: > >> The problem with using a pool or per-process spinlock is that it keeps the >> contention in the process domain, rather than thread domain. For >> multithreaded processes this will give the same contention as a global >> scheduler lock, only slightly reduced in scope. I'd like to solve this in >> such a way that we don't have to revisit it again. >> >> I think I'm going to make the rusage struct per-thread and aggregate it on >> demand. There will be a lot of code churn, but it will be simple. There >> are > > Ugh. > >> a few cases where which will be complicated, and cpulimit is one of them. > > No, cpulimit is simple because it can be fuzzy, unlike calcru() which require > the rusage to be up to date. cpulimit is complicated because it requires aggregate statistics from all threads like rusage. It may be queried infrequently however. It's just one of the few cases where we actually examine the values as if we still only have one thread per process. > > I see how rusage accumulation can help for everything _except_ the > runtime and tick counts (i.e., for stuff updated by statclock()). For > the runtime and tick counts, the possible savings seem to be small and > negative. calcru() would have to run the accumulation code and the > accumulation code would have to acquire something like sched_lock to > transfer the per-thread data (since the lock for updating that data > is something like sched_lock). This is has the same locking overheads > and larger non-locking overheads than accumulating the runtime directly > into the rusage at context switch time -- calcru() needs to acquire > something like sched_lock either way. Yes, it will make calcru() more expensive. However, this should be infrequent relative to context switches. It's only used for calls to getrusage(), fill_kinfo_proc(), and certain clock_gettime() calls. The thing that will protect mi_switch() is not process global. I want to keep process global locks out of mi_switch() or we reduce concurrency for multi-threaded applications. Jeff > > Bruce >