Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 11 Mar 1998 13:48:39 -0500 (EST)
From:      Peter Dufault <dufault@hda.com>
To:        mi@aldan.algebra.com (Mikhail Teterin)
Cc:        freebsd-current@FreeBSD.ORG
Subject:   Re: idprio/rtprio
Message-ID:  <199803111848.NAA26056@hda.hda.com>
In-Reply-To: <199803111740.MAA00835@rtfm.ziplink.net> from Mikhail Teterin at "Mar 11, 98 12:40:58 pm"

next in thread | previous in thread | raw e-mail | index | archive | help
> Is the <subj> broken right now?
> 
> I upgraded to current as of Mar 8, but only rebooted to the new
> kernel today.
> 
> First, contrary to what the manpage says, an ordinary user can no
> longer run idprio.
> 
> Should I file a PR?

The code comment shows that is done on purpose to avoid priority
inversion.

> Now, something less obvious. I run rc5des (start it as myself, then
> make it idprio as SU). The machine slows down more then it used to
> under the same conditions. Top reports the rc5des' nice level as 31:
> 
> CPU states:  1.1% user, 97.4% nice,  1.1% system,  0.4% interrupt,  0.0% idle
> Mem: 3444K Active, 38M Inact, 14M Wired, 5112K Cache, 7620K Buf, 1656K Free
> Swap: 96M Total, 3320K Used, 93M Free, 3% Inuse
> 
>   PID USERNAME PRI NICE  SIZE    RES STATE    TIME   WCPU    CPU COMMAND
>   729 mi       101  31  1060K   292K RUN     14:53 97.35% 97.35% rc5des
>   424 mi         2   0  4216K  3392K select   0:54  0.38%  0.38% Xaccel
>   824 root      29   0   820K   760K RUN      0:00  0.84%  0.31% top
>   455 mi         2   0   264K   496K select   0:00  0.04%  0.04% xload
> 
> Load is 1.44-1.55 -- it was at the strict 1.0 before, unless I was
> running something else that was cpu. hungry.
> 

I broke it at 1.47 of kern_synch - idle priority processes
are not getting preempted until the
next round robin interval instead of as soon as a higher priority
process is runnable.

I did this locally a while ago so I have to dig up why I added
that test to only do need_resched for the same type of process. 
Eliminating that check in maybe_resched for the scheduler types
should set things back the way they were.  I'll run a few tests
with that off and see why I added it.

Peter

-- 
Peter Dufault (dufault@hda.com)   Realtime development, Machine control,
HD Associates, Inc.               Safety critical systems, Agency approval

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message



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