Re: [External] Re: [PATCH] sched/topology: Optimized copy default topology in sched_init_numa()

[Hao Jia]

On 2022/7/12 Valentin Schneider wrote:
> On 11/07/22 18:28, Hao Jia wrote:
> > On 2022/7/4 Valentin Schneider wrote:
> > > It's not a very hot path but I guess this lets you shave off a bit of boot
> > > time... While you're at it, you could add an early
> > Thanks for your time and suggestion.
> > >     if (nr_node_ids == 1)
> > >             return;
> >
> > This will cause the values of sched_domains_numa_levels and
> > sched_max_numa_distance to be different from before, and
> > sched_domains_numa_levels may cause the return value of
> > sched_numa_find_closest() to be different.
> > I'm not sure if it will cause problems.
>
> True, we need to be careful here, but those are all static so they get
> initialized to sensible defaults (zero / NULL pointer).
>
> sched_numa_find_closest() will return nr_cpu_ids which make sense, so I
> think we can get away with an early return

Yes, this may affect the return value of housekeeping anycpu(), which 
doesn't seem to be a problem.

> > > since !NUMA systems still go through sched_init_numa() if they have a
> > > kernel with CONFIG_NUMA (which should be most of them nowdays) and IIRC
> > > they end up with an unused NODE topology level.
> >
> > I'm confused why most !NUMA systems enable CONFIG_NUMA in the kernel?
> > Maybe for scalability?
>
> It just makes things easier on a distribution point of view - just ship a
> single kernel image everyone can use, rather than N different images for N
> different types of systems.
>
> AFAIA having CONFIG_NUMA on an UMA (!NUMA) system isn't bad, it just adds
> more things in the sched_domain_topology during boot time which end up
> being unused.

Thank you very much for your answer.

Thinks,
Hao

>