Re: Processor sets, affinity, real-time extensions

["Mindaugas R." <rmind%NetBSD.org@localhost>]

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

Well, POSIX allows such behaviour:

http://www.opengroup.org/onlinepubs/000095399/functions/nice.html

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?

Thanks!

-- 
Best regards,
Mindaugas
www.NetBSD.org