[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Processor sets, affinity, real-time extensions
Andrew Doran <ad%netbsd.org@localhost> wrote:
> o 'nice' doesn't work with SCHED_M2, which is a regression. Asking people
> to use schedctl doesn't really wash, because nice is specified by POSIX,
> works on every other Unix type system and has been around for over 20
Well, POSIX allows such behaviour:
However, I will implement 'nice' functionality by giving priority boost like
in SCHED_IA class (modification of interactivity). My point is that SCHED_TS
(that is, SCHED_OTHER) is a different design, and modification of _dynamic_
priority by user would make things worse than better. We really need to get
SCHED_FSS class - this is where 'nice' makes sense.. :)
> o SCHED_4BSD doesn't provide the new features and I'm strongly of the
> opinion that's a bug. By providing pluggable schedulers we gave people
> options. By fragmenting the feature set by scheduler we are taking those
> options away again.
- It is not worth renovating SCHED_4BSD, when we have a modern
reimplementation; where is the benefit?
- It looks for me that main argument to use SCHED_4BSD is simplicity;
renovation would make it complex.
Anyway, I do not mind doing this.
> o I mentioned that I don't like how we deal with on-processor migration
> in mi_switch() because it's complicated - and mi_switch() is already too
> complicated. I'll try to think of a better way to handle it.
How about using cross-call as you mentioned, just performing migration from
xcall's thread? Would that be too heavy?
Main Index |
Thread Index |