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>