Scott Cheloha <scottchel...@gmail.com> wrote:
> On Thu, Aug 03, 2023 at 09:09:30AM -0600, Theo de Raadt wrote:
> > Scott Cheloha <scottchel...@gmail.com> wrote:
> >
> > > > > How about this. Kill the spc_ldavg calculation. Its use is more then
> > > > > questionable. The cpu selection code using this is not wroking well
> > > > > and
> > > > > process stealing will do the rest.
> > >
> > > This is more or less what I said yesterday. The per-CPU load average
> > > is not useful for deciding where to put a thread.
> >
> > I guess you have not been reading mpi's scheduler diff. The entire idea
> > of "placing a thread" is 1980's single-processor flawed.
>
> Dude, I'm not talking about mpi's patch, I'm talking about what's in
> the tree.
>
> Given the current state of the scheduler, we can throw out spc_ldavg.
> It isn't necessary.
>
> > > Of the variables we
> > > have available to consider, only the current length of the runqueue is
> > > useful.
> >
> > No, that concept is also broken.
>
> Again, I am talking about the current scheduler.
>
> Said another way: the current approach can limp along just fine using
> only the runqueue length. We can get rid of spc_ldavg without
> worrying about it.
I'm just saying all of us need to recognize that it is impossible to
defend the in-tree code.
Anways, you said "the current length of the runqueue is useful". It is
only useful in choosing a different stupid runqueue.
