Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 29 Oct 2012 07:27:12 +1100 (EST)
From:      Peter Jeremy <peter@rulingia.com>
To:        FreeBSD-gnats-submit@FreeBSD.org
Subject:   bin/173175: atrun(8) load monitoring does not handle SMP
Message-ID:  <201210282027.q9SKRCiU060995@server.rulingia.com>
Resent-Message-ID: <201210282030.q9SKU1xv020205@freefall.freebsd.org>

next in thread | raw e-mail | index | archive | help

>Number:         173175
>Category:       bin
>Synopsis:       atrun(8) load monitoring does not handle SMP
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sun Oct 28 20:30:01 UTC 2012
>Closed-Date:
>Last-Modified:
>Originator:     Peter Jeremy
>Release:        FreeBSD 8.3-STABLE amd64
>Organization:
n/a
>Environment:
System: FreeBSD server.rulingia.com 8.3-STABLE FreeBSD 8.3-STABLE #18 r237444M: Sun Jul 8 10:47:08 EST 2012 root@server.rulingia.com:/var/obj/usr/src/sys/server amd64

>Description:
	By default, atrun(8) stops executing batch jobs if the 1-minute
	load average exceeds 1.5.  Whilst this may be reasonable on a
	UP host, it cuts in far too early on SMP hosts.

	Within the base system, only atrun(8), sendmail(8) and libgomp
	use the load average to control behaviour.  libgomp and sendmail
	already compensate for the number of CPUs but atrun has a fixed
	default limit.

>How-To-Repeat:
	Code inspection.

	Eg, on a 4-way SMP host, queue a batch(1) or at(1) job as well as
	2 CPU-bound processes.  Note that the batch/at job does not run
	even though the system is only 50% loaded.

>Fix:
	The simplest fix is to scale the 1.5 by the number of CPUs.



>Release-Note:
>Audit-Trail:
>Unformatted:



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201210282027.q9SKRCiU060995>