tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Processor sets, affinity, real-time extensions

Andrew Doran <> 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
>   years.

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.

My opinion:
- 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?


Best regards,

Home | Main Index | Thread Index | Old Index