Bug 112101 - atd ignores NCPUS>1 for batch commands load limit
atd ignores NCPUS>1 for batch commands load limit
Status: CLOSED DEFERRED
Product: Fedora
Classification: Fedora
Component: at (Show other bugs)
1
All Linux
medium Severity medium
: ---
: ---
Assigned To: Marcela Mašláňová
Mike McLean
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-12-14 13:37 EST by Michal Szymanski
Modified: 2007-11-30 17:10 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-08-22 11:02:10 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Michal Szymanski 2003-12-14 13:37:00 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20030925

Description of problem:
According to man page for "atd", the system average load limit for a
batch command to be executed is hard-compiled as 0.8. Man page even
notes that for SMP systems with more than one processor, this should
be raised to some value between NCPUS-1 and NCPUS (by using "-l"
option to 'atd' in /etc/init.d/atd). This is, however, easy to forget
and somewhat annoying (it would probably require to re-edit the script
each time an upgrade is made).


Version-Release number of selected component (if applicable):
any "at" since RH6 (at least)

How reproducible:
Always

Steps to Reproduce:
1.boot a SMP system
2.run a single long-running job
3.queue a batch job
    

Actual Results:  If the load average after running the "long" job
raises to about 1, the batch job will not be executed until the "long"
job finishes.

Expected Results:  With, say, 2 CPUS system and one long job running,
a batch queue should be executed without any delay

Additional info:

I'd put the "atd-compiled" load limit to something like
sysconf(_SC_NPROCESSORS_ONLN)-0.2
It's worth noting that a simple script-level solution like 
"grep processor /proc/cpuinfo | wc -l"
may fail on machines other than i386 (e.g. on Alphas)
Comment 1 Jason Vas Dias 2005-06-03 12:11:54 EDT
Sorry this bug somehow slipped through the cracks. 
Yes, I agree the 0.8 fixed default maximum load average 
is unreasonable. 
Perhaps it might be more reasonable to disable it entirely
unless the '-l' option is given.
I'm investigating and will consider what to do for the next
version.
Comment 2 Matthew Miller 2006-07-11 13:37:12 EDT
Fedora Core 1 is maintained by the Fedora Legacy project for security updates
only. If this problem is a security issue, please reopen and reassign to the
Fedora Legacy product. If it is not a security issue and hasn't been resolved in
the current FC5 updates or in the FC6 test release, reopen and change the
version to match.

Thanks!

NOTE: Fedora Core 1 is reaching the final end of support even by the Legacy
project. After Fedora Core 6 Test 2 is released (currently scheduled for July
26th), there will be no more security updates for FC1. Please use these next two
weeks to upgrade any remaining FC1 systems to a current release.

Comment 3 Marcela Mašláňová 2006-08-22 11:02:10 EDT
It's not security bug and support for FC1 was stopped. I'm closing it.

Note You need to log in before you can comment on or make changes to this bug.