From owner-freebsd-arch@FreeBSD.ORG Tue May 29 18:58:12 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 B00B816A476 for ; Tue, 29 May 2007 18:58:12 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.freebsd.org (Postfix) with ESMTP id 2C94C13C48C for ; Tue, 29 May 2007 18:58:11 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id l4TIw0kY071297; Tue, 29 May 2007 14:58:00 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-arch@freebsd.org Date: Tue, 29 May 2007 14:56:38 -0400 User-Agent: KMail/1.9.6 References: <20070529105856.L661@10.0.0.1> In-Reply-To: <20070529105856.L661@10.0.0.1> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200705291456.38515.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Tue, 29 May 2007 14:58:00 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/3323/Tue May 29 08:10:43 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: 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 18:58:12 -0000 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. -- John Baldwin