Re: Current ULE state and plans (was Re: HMP scheduling on FreeBSD)

> Please, do not deprecate 4BSD.

4BSD will be deprecated provided we can fix ULE's mentioned problems as expected, since, AFAIK, they are the only cases where 4BSD can fare better.

> Although it's been
> a long time since I benchmarked 4BSD vs ULE with my
> OpenMPI-based code, 4BSD handled the work load much
> better than ULE.  Yes, I made Jeff aware of the
> situation.

Did this notification produce any useful discussion, and even an analysis?

> It's unclear how you conclude that 4BSD is lightly
> tested.  Maybe 4BSD simply works and there's nothing
> to report.

Simple:
- 4BSD has not been the default scheduler since more than 18 years, and the choice of scheduler must be done at kernel compilation time.  That has reduced its exposure to those people that will install custom kernels with it explicitly re-enabled.  I'm willing to bet this is a very small cohort.  Feedbacks would of course be better.
- During that course, some 4BSD bugs have persisted for years (such as incorrect %CPU reporting) and, AFAIK, almost nobody complained.
So it seems unlikely we are in the "simply works and there's nothing to report" case.
That said, I assume it still mostly works, and when doing runqueue changes took care to avoid disturbing its behavior (and, in one case, likely improved it).  But I only test it very lightly.

Going forward, I'll send a call for testing once the mentioned problems are fixed.  Then, re-testing your scenario would be helpful and the most constructive move.  There's no point in keeping 4BSD if there's not a single scenario where it is clearly better.

-- 
Olivier Certner