From: Claudio Jeker <cjeker@diehard.n-r-g.com>
Subject: Re: print intel core type info in dmesg
To: David Gwynne <david@gwynne.id.au>, tech@openbsd.org
Date: Wed, 23 Jul 2025 21:08:29 +0200

On Wed, Jul 23, 2025 at 11:59:25AM -0600, Theo de Raadt wrote:
> Claudio Jeker <cjeker@diehard.n-r-g.com> wrote:
> 
> > On Wed, Jul 23, 2025 at 10:36:06AM -0600, Theo de Raadt wrote:
> > > Claudio Jeker <cjeker@diehard.n-r-g.com> wrote:
> > > 
> > > > On Wed, Jul 23, 2025 at 08:42:30AM -0600, Theo de Raadt wrote:
> > > > > I think this overstates the importance of this difference over other
> > > > > parts of the cpu description.  I think there's a lot of optimism that
> > > > > this matters for performing work.  Why do we need to print this, if
> > > > > we aren't taking this into account during processing because we have no
> > > > > code to make use of this difference?
> > > > 
> > > > Adding support for this can be only done if we have topology information
> > > > that has more information.
> > > 
> > > The provided diff does not place the information in a data structure so
> > > that the kernel can make a decision.
> > > 
> > > It just prints it.  Things printed into dmesg cannot be taken into account.
> > 
> > It is a first step. We need to rethink the code around __HAVE_CPU_TOPOLOGY
> > which is possible when there is code around to identify CPUs.
> 
> The code which exists is only for hw.smt
> 
> There is nothing to rethink.  __HAVE_CPU_TOPOLOGY is an overly broad name
> for doing a tiny MD operation of skipping SMT cpus.

It is like many things something that was started as a big vision and
then it lost all steam right after the first commit.
Our topology data is shitty and yes, the only thing we use it for is
hw.smt which is very sad.

> > I know this is a baby step but without that I'm certain no other progress
> > will happen.
> 
> I don't see it this way.  There is nothing in the current scheduler data
> structures and code which leads me to believe it can use this information.
> It comes down to the problem of: If you have a process, and you know some
> things about that process, how do you know which cpu you should queue it to.
> First problem is we know nothing differentiateable about any process to make
> a decision which type of cpu to queue it to.  And of course, since this
> is mentioning kern_sched.c, this is not about running it, this is about
> queueing it!  And that's where it all goes wrong, it chooses a cpu it will
> run the job on, at some unknown point in the future.  So it uses no information
> about the process, to make a decision to run it later, on some class of cpu,
> and by placing it in that queue, it WILL NOT RUN IT ELSEWHERE.
> 
> In my mind, that is the definition of dumb cubed.

I guess we will keep the shitty scheduler for the next 10 years. 
Because nobody will ever touch it. At least I'm very close to walk away
from it and just close that chapter.

There are many ways this can tackled but one thing is sure, nothing can
happen if there is no way to group CPUs.

-- 
:wq Claudio