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,
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
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 implement a
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's whatever the
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 only by
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 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
tsleep()
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 priority
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 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
mechanism to
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 part
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 something
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 cause
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
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
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, highest
[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,
17 matches
Mail list logo
