From owner-freebsd-arch@FreeBSD.ORG  Tue May 29 18:01:43 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 34D6A16A400
	for <arch@freebsd.org>; Tue, 29 May 2007 18:01:43 +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 D93DA13C448
	for <arch@freebsd.org>; Tue, 29 May 2007 18:01:42 +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
	l4TI1enX042960
	(version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO)
	for <arch@freebsd.org>; Tue, 29 May 2007 14:01:41 -0400 (EDT)
	(envelope-from jroberson@chesapeake.net)
Date: Tue, 29 May 2007 11:01:36 -0700 (PDT)
From: Jeff Roberson <jroberson@chesapeake.net>
X-X-Sender: jroberson@10.0.0.1
To: arch@freebsd.org
Message-ID: <20070529105856.L661@10.0.0.1>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: 
Subject: 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:01:43 -0000

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().

Jeff