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

Hi,

> If surrounding code is changed (and that code might have
> a negative effect on 4BSD), would it not fall on an individual
> making the change to do his/her due diligence to ensure that
> it does not break surrounding code?

Certainly.  But if due diligence was in general enough, do you think that people would be building, e.g., automated test suites?  companies have quality assessment teams? etc.

> May be this
> 
>    commit e745d729be60a47b49eb19c02a6864a747fb2744
>    Author: Alexander Motin <mav@FreeBSD.org>
>    Date:   Tue Sep 21 18:14:22 2021 -0400
> 
>      sched_ule(4): Improve long-term load balancer.
> 
> fixed the issue.

That may considerably improve the situation.  But until that is tested, we don't know for sure.

> I'll see what I can find.

Thanks, that could be helpful.
 
> > So, claiming that ULE isn't a good choice on HPC now is perhaps an overstatement, don't you think?
> 
> As you noted "Code is not free.", well neither is time
> and I had other work obligations.

Which is perfectly understandable.  I was criticizing the "ULE *is* a poor choice for a HPC cluster" statement, which at this point is very weak.

That doesn't necessarily mean it's untrue, but rather that we don't have proof of that now.  What we only have are proofs of problems happening long ago, and ULE has changed significantly over the last ~10 years (not in the general principles, but in important details).  That's why I'm asking for tests (again, not necessarily now, but after the last fixes).

Thanks and regards.

-- 
Olivier Certner