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

> Why remove functioning code that people actually use?

How can you be sure it is functioning correctly?  Have you reviewed it?  Has it been tested on a variety of workloads?  What does guarantee it will not break, more or less badly, when some code surrounding it is changed, even when these changes are done carefully?

And who is using it, exactly? You count for 1. Given the past threads on the topic, I expect a few more, but can we even reach 10 or 20, I wouldn't bet on it.

Code is not free.  As I've just said, the majority of the burden when maintaining schedulers is testing with different scenarios, possibly also working on tools to automate what we can, which however currently seem far from being able to model the whole reality.  Who is going to perform that?  Are we going to continue to ship under-tested code, creating among users a false sense of real support?

And finally, again, what would be the point of keeping 4BSD around if we reach a state where it has no advantages at all?
 
> Of course! I was one of the original testers of ULE when Jeff
> first committed it to the tree.  I suppose I can dig out my
> email archive to see if I still have our exchanges.

That may be useful.  If possible, I'd like to read them.

> It simply works. <-- There's your feedback.

That's only *your* feedback.  One data point on one workload.  I can imagine that this one matters to you the most, but the world is... bigger.
 
> ULE is/was a poor choice for a HPC cluster.  But, as I stated, I have
> not benchmarked ULE vs 4BSD in over a decade.  I gave up, and went
> with the path of least resistance where all of my custom kernels use
> 4BSD.

So, claiming that ULE isn't a good choice on HPC now is perhaps an overstatement, don't you think?

Don't get me wrong, I'm not asking you to test it again now.  But I'll ask so after the fixes are pushed.

>   Here's an example of the issue I reported long ago:
> 
> https://lists.freebsd.org/pipermail/freebsd-hackers/2008-October/026375.html

That's very interesting, and shows typical symptoms of problem number 2.  But of course we cannot say for sure, only real testing will tell.

> That's at most a cosmetic bug.  For people using FreeBSD in
> an HPC environment, the important metric is wall-clock time.

That was just an example.  Off the top of my head, I saw some others, but don't recall them now.

> I'll see if can do testing, but that can be problematic
> as I try to keep world and ports in sync, and lately
> ports has been a challenge.

If you have enough time and motivation, you can test now, but what is really important is that you test after the fixes.

Thanks and regards.

-- 
Olivier Certner