Hi,
i understand that this means maybe a somwthat
large change in the system, but what do you think
if we have a lok at implementing the CPU scheduler using
weights instead of strict priorities ?
Do we have parts of the kernel which rely on priority
to implement locking etc ?
This would not be too different from what the EclipseBSD people
did, and the code i recently committed to dummynet can be easily
reused to this purpose, and it is efficient.
With a little bit of guidance (I am not too familiar with that area
of the code) i think we can do something good with little
effort.
cheers
luigi
> On Sun, 11 Jun 2000, Jacob A. Hart wrote:
>
> > On Fri, Jun 09, 2000 at 08:28:06PM -0400, Brian Fundakowski Feldman wrote:
> > >
> > > The diff should make a process at -20 which uses all available CPU
> > > schedule just slightly the ahead of a process at +20 which uses no CPU.
> > > A process which uses full CPU at 0 niceness would have a priority of
> > > 128, whereas a process using no CPU at 0 niceness would have a priority
> > > of 90. All processes will always have a priority less than or equal to
> > > 128, which is the priority at which a process with a niceness of +20
> > > always runs at. A +20 process won't get better priority than anything
> > > else, period. Try it out, see how it works for you:)
> >
> > I tried this patch today.
> >
> > While it didn't quite fix the problem, it sure made for some interesting
> > pacman gameplay. ;-)
>
> Yeah, I tried it out myself. I didn't actually think beforehand (hence the
> testing...) why it would be bad for a process of niceness -20 to always
> have better than the last priority in every case... I tried it with
> MAME and it took a long time before my "escape" key event registered
> (X not getting run...).
>
> I'm thinking of ways to make the algorithm both good for people who need
> (err... want) low-priority background processes only to run when there's
> free time, and high-priority processes run but not to the exclusion of
> everything else. The whole scheduling algorithm proper is quite tricky
> to do very well; previously, it had most of the properties we want, but
> it also easily allowed for deadlocks.
>
> > Using idprio as Volodymyr suggested seems to be a viable workaround. You
> > mentioned in another message that idprio could potentially deadlock my
> > machine, though. Under what conditions could this happen (and how likely
> > is it to occur)?
> >
> >
> > -jake
> >
> > --
> > Jacob A. Hart <[EMAIL PROTECTED]>
> > Powered by: FreeBSD 5.0-CURRENT #18: Sun Jun 11 19:25:03 EST 2000
> >
>
> --
> Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! /
> [EMAIL PROTECTED] `------------------------------'
>
>
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
