From owner-freebsd-arch@FreeBSD.ORG Tue May 29 19:19: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 7532116A46B; Tue, 29 May 2007 19:19: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 322B213C447; Tue, 29 May 2007 19:19:40 +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 l4TJJbxk068785 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Tue, 29 May 2007 15:19:38 -0400 (EDT) (envelope-from jroberson@chesapeake.net) Date: Tue, 29 May 2007 12:19:33 -0700 (PDT) From: Jeff Roberson X-X-Sender: jroberson@10.0.0.1 To: John Baldwin In-Reply-To: <200705291456.38515.jhb@freebsd.org> Message-ID: <20070529121653.P661@10.0.0.1> References: <20070529105856.L661@10.0.0.1> <200705291456.38515.jhb@freebsd.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 19:19:40 -0000 On Tue, 29 May 2007, John Baldwin wrote: > On Tuesday 29 May 2007 02:01:36 pm Jeff Roberson wrote: >> I'm working with Attilio to break down rusage further to be per-thread in >> places where it is protected by the global scheduler lock. To support >> this, I am interested in moving the rlimit cpulimit check into userret(), >> or perhaps ast(). Is there any reason why we need to check this on every >> context switch? Any objections to moving it? Eventually it will require >> a different lock from the one we obtain to call mi_switch(). > > I think using a per-process spin lock (or a pool of spin locks) would be a > good first step. I wouldn't do anything more complicated unless the simple > approach doesn't work. The only reason to not move the check into userret() > would be if one is worried about threads chewing up CPU time while they are > in the kernel w/o bouncing out to userland. Also, it matters which one > happens more often (userret() vs mi_switch()). If on average threads perform > multiple system calls during a single time slice (no idea if this is true or > not), then moving the check to userret() would actually hurt performance. 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 a few cases where which will be complicated, and cpulimit is one of them. Jeff > > -- > John Baldwin >