From owner-freebsd-bugs@FreeBSD.ORG Fri May 16 20:00:00 2014 Return-Path: Delivered-To: freebsd-bugs@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C0327839 for ; Fri, 16 May 2014 20:00:00 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9D53422EE for ; Fri, 16 May 2014 20:00:00 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s4GK00Qs093471 for ; Fri, 16 May 2014 20:00:00 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s4GK00CA093470; Fri, 16 May 2014 20:00:00 GMT (envelope-from gnats) Resent-Date: Fri, 16 May 2014 20:00:00 GMT Resent-Message-Id: <201405162000.s4GK00CA093470@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-bugs@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Dustin Wenz Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 817845B0 for ; Fri, 16 May 2014 19:54:01 +0000 (UTC) Received: from cgiserv.freebsd.org (cgiserv.freebsd.org [IPv6:2001:1900:2254:206a::50:4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6F03E22A7 for ; Fri, 16 May 2014 19:54:01 +0000 (UTC) Received: from cgiserv.freebsd.org ([127.0.1.6]) by cgiserv.freebsd.org (8.14.8/8.14.8) with ESMTP id s4GJs0iC072293 for ; Fri, 16 May 2014 19:54:00 GMT (envelope-from nobody@cgiserv.freebsd.org) Received: (from nobody@localhost) by cgiserv.freebsd.org (8.14.8/8.14.8/Submit) id s4GJs0RO072292; Fri, 16 May 2014 19:54:00 GMT (envelope-from nobody) Message-Id: <201405161954.s4GJs0RO072292@cgiserv.freebsd.org> Date: Fri, 16 May 2014 19:54:00 GMT From: Dustin Wenz To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Subject: kern/189870: Possible bad CPU resource limit assumption in kern_racct.c X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 May 2014 20:00:00 -0000 >Number: 189870 >Category: kern >Synopsis: Possible bad CPU resource limit assumption in kern_racct.c >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: update >Submitter-Id: current-users >Arrival-Date: Fri May 16 20:00:00 UTC 2014 >Closed-Date: >Last-Modified: >Originator: Dustin Wenz >Release: FreeBSD 10.0 r265159 >Organization: eBureau >Environment: FreeBSD ixsys02.office.ebureau.com 10.0-STABLE FreeBSD 10.0-STABLE #2 r265159: Thu May 1 15:07:17 CDT 2014 root@setup.dc.ebureau.com:/usr/obj/usr/src/sys/ALTQKERNEL amd64 >Description: I've been having a difficult time using the new CPU percentage limits in FreeBSD 10. It seems that if you specify a limit beyond 110% (say, 500%), the process (or jail, etc.) that you are trying to control becomes unthrottled, and can use the CPU until all logical cores are busy. >How-To-Repeat: Run a process that uses 20 cores at 100% utilization (2000%) in total. Attempt to limit that process to only 1000% using rctl. rctl -a 'process:PID:pcpu:deny=1000/process' Note that the process is not throttled. >Fix: My workaround is to remove these lines in kern_racct.c from function racct_alloc_resource(): if ((resource == RACCT_PCTCPU) && (racct->r_resources[RACCT_PCTCPU] > 100 * 1000000)) racct->r_resources[RACCT_PCTCPU] = 100 * 1000000; I'm not sure if there needs to really be any cap on the reported %CPU from the kernel. If so, it should be at least the number of logical cores available * 100 * 1000000. >Release-Note: >Audit-Trail: >Unformatted: