From owner-freebsd-arch@FreeBSD.ORG  Tue May 29 18:12:02 2007
Return-Path: <owner-freebsd-arch@FreeBSD.ORG>
X-Original-To: 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 4D3B116A421
	for <arch@freebsd.org>; Tue, 29 May 2007 18:12:02 +0000 (UTC)
	(envelope-from bright@elvis.mu.org)
Received: from elvis.mu.org (elvis.mu.org [192.203.228.196])
	by mx1.freebsd.org (Postfix) with ESMTP id 3FBB913C48A
	for <arch@freebsd.org>; Tue, 29 May 2007 18:12:02 +0000 (UTC)
	(envelope-from bright@elvis.mu.org)
Received: by elvis.mu.org (Postfix, from userid 1192)
	id C89381A4D84; Tue, 29 May 2007 11:13:10 -0700 (PDT)
Date: Tue, 29 May 2007 11:13:10 -0700
From: Alfred Perlstein <alfred@freebsd.org>
To: Jeff Roberson <jroberson@chesapeake.net>
Message-ID: <20070529181310.GP21795@elvis.mu.org>
References: <20070529105856.L661@10.0.0.1>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20070529105856.L661@10.0.0.1>
User-Agent: Mutt/1.4.2.2i
Cc: 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 <freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
	<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
	<mailto:freebsd-arch-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 29 May 2007 18:12:02 -0000

* Jeff Roberson <jroberson@chesapeake.net> [070529 11:07] 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().

Er, as long as it's checked each place where we can issue a signal
so a SIGXCPU can be sent when tsleep/cv_wait_sig...

right?

-Alfred