Bug 13252

Summary: niced jobs don't behave really nice
Product: Base System Reporter: holger.kipp <holger.kipp>
Component: kernAssignee: freebsd-bugs (Nobody) <bugs>
Status: Closed FIXED    
Severity: Affects Only Me    
Priority: Normal    
Version: Unspecified   
Hardware: Any   
OS: Any   

Description holger.kipp 1999-08-19 11:10:00 UTC 
Niced jobs use up to much CPU time if other jobs are running (or are
supposed to be running instead).

Fix: 

No idea, but under my Linux implementation
"Linux clausthal 2.0.36 #5 Wed Jan 20 14:23:31 MET 1999 i686 unknown"
I tested this with SETI@home with nice -19, and there was no slowdown
whatsoever noticeable if running other processes. The niced SETI@home
job is really only using the CPU-time the idle-process would otherwise
use.
How-To-Repeat: Run some timecritical software (eg amanda) and install some other jobs
that are supposed to _really_ run in the background (ie start them with
nice -19). Specifically suited are CRACK and SETI@home. Then have a look
at the jobs with top and see the niced jobs running with > 80% CPU usage
even though amanda with dumper and gzip are running...
Comment 1 Sheldon Hearn freebsd_committer freebsd_triage 1999-08-19 12:45:05 UTC 
State Changed
From-To: open->closed

Duplicate of PR 12381. This problem is fixed in RELENG_3, in 
rev 1.16.2.1 of src/sys/i386/isa/intr_machdep.c .
Comment 2 Sheldon Hearn freebsd_committer freebsd_triage 1999-08-19 15:21:19 UTC 
State Changed
From-To: closed->suspended

As Bruce Evans points out, this problem still exists in RELENG_2_2. 
I'm leaving this suspended since RELENG_2_2 isn't completely dead.
Comment 3 Jonathan Chen freebsd_committer freebsd_triage 2001-08-05 10:46:40 UTC 
State Changed
From-To: suspended->closed

RELENG_2_2 is completely dead, or so we hope.
Comment 4 Bruce Evans 2001-08-05 13:40:56 UTC 
On Sun, 5 Aug 2001 jon@FreeBSD.ORG wrote:

> Synopsis: niced jobs don't behave really nice
>
> State-Changed-From-To: suspended->closed
> State-Changed-By: jon
> State-Changed-When: Sun Aug 5 02:46:40 PDT 2001
> State-Changed-Why:
> RELENG_2_2 is completely dead, or so we hope.

This is the same bug as in the suspended PR 12381.  The fix referred
to in the followup (rev.1.16.2.1 of isa/intr_machdep.c) is for a
different bug.  See PR 12381 for a much longer followup including a
correct reference to the fix.

Current status of this bug:
- never fixed in any 2.* or 3.* release.
- PR 12381 hidden^Wsuspended awaiting commits to RELENG_3.
- fixed in all 4.* releases by inheriting rev.1.83 of kern_synch.c (etc.).
- re-broken in -current in rev.1.90 of kern_sync.c (etc.).
- made worse in -current by SMPng prioritization changes (these squeeze
  the priority space, and the priority space was already too congested
  to work properly).

Bruce
Comment 5 Jonathan Chen freebsd_committer freebsd_triage 2001-08-05 16:34:50 UTC 
On Sun, Aug 05, 2001 at 10:40:56PM +1000, Bruce Evans wrote:
> This is the same bug as in the suspended PR 12381.  The fix referred
> to in the followup (rev.1.16.2.1 of isa/intr_machdep.c) is for a
> different bug.  See PR 12381 for a much longer followup including a
> correct reference to the fix.
> 
> Current status of this bug:
> - never fixed in any 2.* or 3.* release.
> - PR 12381 hidden^Wsuspended awaiting commits to RELENG_3.
> - fixed in all 4.* releases by inheriting rev.1.83 of kern_synch.c (etc.).
> - re-broken in -current in rev.1.90 of kern_sync.c (etc.).
> - made worse in -current by SMPng prioritization changes (these squeeze
>   the priority space, and the priority space was already too congested
>   to work properly).

Oops, this will teach me to never blindly trust what somebody else wrote a 
long time ago...  In any case, we can probably leave this closed as it is a 
duplicate of another PR.  Thanks for catching this, Bruce.

-Jon