Luigi Rizzo wrote:
>
> Don't know how interesting this can be, but i am writing
> (no plans to commit it, unless people find it interesting)
> some code to implement a weight-based instead of priority-based
> scheduler. The code is basically the WF2Q+ scheme which is
> already part of dummynet, a
On Sat, 22 Dec 2001, Jake Burkholder wrote:
> Apparently, On Sat, Dec 22, 2001 at 06:48:26PM +1100,
> Bruce Evans said words to the effect of;
> > Index: kern_synch.c
> > ===
> > RCS file: /home/ncvs/src/sys/kern/kern_synch.c,v
On Sat, 22 Dec 2001, Luigi Rizzo wrote:
> On Sat, Dec 22, 2001 at 06:48:26PM +1100, Bruce Evans wrote:
> > Most of the changes here are to fix style bugs. In the NEW_SCHED case,
> > the relative weights for each priority are determined by the niceweights[]
> > table. kg->kg_estcpu is limited on
On Fri, 21 Dec 2001, John Baldwin wrote:
> On 21-Dec-01 Bruce Evans wrote:
> > On Fri, 21 Dec 2001, Luigi Rizzo wrote:
> >> the original priority should be somewhere and accessible,
> >> either directly or through some function. Otherwise how
> >> do we know what to pass to tsleep() ?
> >
> > It'
Apparently, On Sat, Dec 22, 2001 at 06:48:26PM +1100,
Bruce Evans said words to the effect of;
> On Fri, 21 Dec 2001, Luigi Rizzo wrote:
>
> > Don't know how interesting this can be, but i am writing
> > (no plans to commit it, unless people find it interesting)
> > some code to implemen
On Sat, Dec 22, 2001 at 06:48:26PM +1100, Bruce Evans wrote:
> On Fri, 21 Dec 2001, Luigi Rizzo wrote:
...
> > This would help removing the ugly property that priority-based
> > have, which is that one process can starve the rest of the system.
>
> Only broken priority-based schedulers have that
On Fri, 21 Dec 2001, Luigi Rizzo wrote:
> Don't know how interesting this can be, but i am writing
> (no plans to commit it, unless people find it interesting)
> some code to implement a weight-based instead of priority-based
> scheduler. The code is basically the WF2Q+ scheme which is
> already
Don't know how interesting this can be, but i am writing
(no plans to commit it, unless people find it interesting)
some code to implement a weight-based instead of priority-based
scheduler. The code is basically the WF2Q+ scheme which is
already part of dummynet, adapted to processes.
It is quite
On 21-Dec-01 Bruce Evans wrote:
> On Fri, 21 Dec 2001, Luigi Rizzo wrote:
>
>> On Sat, Dec 22, 2001 at 12:46:40AM +1100, Bruce Evans wrote:
>> > I think pri_native is just an implementation detail which shouldn't
>> > be used or visible to threads. It used used by the priority propagation
>> >
On Fri, 21 Dec 2001, Luigi Rizzo wrote:
> On Sat, Dec 22, 2001 at 12:46:40AM +1100, Bruce Evans wrote:
> > I think pri_native is just an implementation detail which shouldn't
> > be used or visible to threads. It used used by the priority propagation
> > mechanism to hold the original pri_level.
On Sat, Dec 22, 2001 at 12:46:40AM +1100, Bruce Evans wrote:
> I think pri_native is just an implementation detail which shouldn't
> be used or visible to threads. It used used by the priority propagation
> mechanism to hold the original pri_level. Threads should just use their
> original priori
On Thu, 20 Dec 2001, John Baldwin wrote:
> On 20-Dec-01 Luigi Rizzo wrote:
> > On Thu, Dec 20, 2001 at 12:16:03PM -0800, John Baldwin wrote:
> >> However, kthreads should tsleep() with their current priority, not PPAUSE.
> >
> > "current" meaning pri_level or pri_native ? What if one tries to
> >
On 20-Dec-01 Luigi Rizzo wrote:
> On Thu, Dec 20, 2001 at 12:16:03PM -0800, John Baldwin wrote:
> ...
>> Priority propagation will already handle things ok. We drop to pri_native
>> after we drop a lock (although if we still hold a contested lock we bump our
>> priority to the min(nativepri, hig
On Thu, Dec 20, 2001 at 12:16:03PM -0800, John Baldwin wrote:
...
> Priority propagation will already handle things ok. We drop to pri_native
> after we drop a lock (although if we still hold a contested lock we bump our
> priority to the min(nativepri, highest priority of threads on contested lo
On 20-Dec-01 Luigi Rizzo wrote:
> On Thu, Dec 20, 2001 at 11:13:27AM -0800, Peter Wemm wrote:
> ...
>> Excellent catch! This particular problem was one of the main reasons
>> why this is still defaulting to 'off'. I have a couple of other changes
>> to it pending commit to fix some of Bruce's c
On Thu, Dec 20, 2001 at 11:13:27AM -0800, Peter Wemm wrote:
...
> Excellent catch! This particular problem was one of the main reasons
> why this is still defaulting to 'off'. I have a couple of other changes
> to it pending commit to fix some of Bruce's complaints, but I hadn't
> noticed the ca
Luigi Rizzo wrote:
> [Cc peter because he introduced this code]
>
> Hi,
> i was trying the following code in -current (basically copied from
> vm_zeropage.c), to implement device polling in the idle loop, and
> noticed that the process would take all of the CPU time. Being
> suspicious that somet
[Cc peter because he introduced this code]
Hi,
i was trying the following code in -current (basically copied from
vm_zeropage.c), to implement device polling in the idle loop, and
noticed that the process would take all of the CPU time. Being
suspicious that something was wrong with priorities, I
18 matches
Mail list logo
