Re: HMP scheduling on FreeBSD

On Wed, 14 Jan 2026 at 08:10, Minsoo Choo <minsoochoo0122@proton.me> wrote:
>
> Greetings,
>
> For the last few days, I've been working on scheduler optimization for heterogeneous cores ("HMP scheduling" from now on) on FreeBSD. After days of reading specs, planning structure, and writing code, I came to a model that can be utilized for implementing HMP scheduling. I opened a first revision on Phabricator (D54674) a few days ago but decided to introduce this model in the mailing list and hear others' opinions.
>

[snip]

yay! thanks for working on this!

I've given you some feedback in the review already and thanks for
working on that.

On the practical side, there's a bunch of infrastructure pieces that
we're missing that I also think would be good to get into
the tree. I started describing them in oliver's hybrid scheduling wiki
page that he mentioned below, but I figure it'll be good
to go into here.

Notably, we don't store the per CPU information about the core
type/description in PCPU anywhere. eg, when we assemble
the description string of a given CPU core, we actually duplicate the
information from CPU core 0. On an ARM hybrid system
we'll print out each core type during boot but only the first core
string gets used and is available when you want all of them.

On the intel side, there's a diff in this email somewhere where the
Intel specific core type is exposed. We have a PCPU value
in the amd64 pcpu arch area, but it's only enumerated and used for a
workaround. It's not exposed anywhere generic so
decisions can be made. Since it's in the arch specific area, there's
not a neat way to expose the "groupings" in a way that
lets userland (and scheduler, but you're looking at that) make
decisions. Eg, if I knew which CPUs were in each class and had
information about the class (eg "this class is superscalar, this class
has more cache, this class is low power") I could
assign services to different CPU sets and then later on have some
policies that let us tweak things based on current system
load and environment.

(This btw is the kind of stuff we have to do at work on our wearable
products to get consistent performance and low battery
usage. There's only so much the scheduler can do before you have to
think about policy, and policy requires available information.. :-)

So, I'd like your ideas on how we can start populating more of the
generic and architecture-specific per CPU information into the PCPU
areas and expose it to userland.

Thanks!


-adrian