From owner-freebsd-arch@FreeBSD.ORG Tue May 29 20:45:44 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 0DC3816A421 for ; Tue, 29 May 2007 20:45:44 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outZ.internet-mail-service.net (outZ.internet-mail-service.net [216.240.47.249]) by mx1.freebsd.org (Postfix) with ESMTP id ECBAF13C46A for ; Tue, 29 May 2007 20:45:43 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Tue, 29 May 2007 13:45:43 -0700 Received: from julian-mac.elischer.org (nat.ironport.com [63.251.108.100]) by idiom.com (Postfix) with ESMTP id E9B7F125B4B; Tue, 29 May 2007 13:45:42 -0700 (PDT) Message-ID: <465C90F5.1000906@elischer.org> Date: Tue, 29 May 2007 13:45:41 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: Jeff Roberson References: <20070529105856.L661@10.0.0.1> <200705291456.38515.jhb@freebsd.org> <20070529121653.P661@10.0.0.1> In-Reply-To: <20070529121653.P661@10.0.0.1> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 20:45:44 -0000 Jeff Roberson wrote: > > 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. So, there should be somewhere to store the aggregated stats from threads that have already exited. > > Jeff > >> >> -- >> John Baldwin >> > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"