cpumask move patch revised - RFC

[Paul Mackerras]

R Sharada writes:

> Yes, you are correct. I did see Nathan's patch on the removal of the
> unnecessary cpu maps. And yes, I am waiting for his patch to go first
> and then have this reworked to match that change.

I have just sent Nathan's patches on to Andrew Morton.

> > Is this really necessary?  Might it go better in a .h file somewhere?
>
> Well, yes, perhaps it could be put in some .h file. However, the idea here
> was that, I just followed the conventions for other functions in chrp_setup.c
> file

Hmmm.  Anything that is defined in one file and referenced in another
should be declared in a header, not in the individual C files.  Put it
in asm-ppc64/smp.h (unless you can think of a better place).  Either
that or move cpumask_setup() into setup.c.

> As regards the of_node_put, discussing with Nathan, I realized that it isn't
> really necessary, even for the last cpu node data structure in the while
> loop. So, this of_node_put will be gone soon, in the next patch.

Note that it is not necessary because np is NULL by the time you exit
the loop.

> > I think it is about time we start making code that will deal with more
> > than 2 cpu_threads, as the processors seem inevitable and not too far off.
> >
> So, can SMT/HMT have more than 2 threads now? or planned in the near future?

Not that I know of. :)  There are diminishing returns from having more
than 2 threads.  If we ever get more than 2 threads we can change the
code then, but that won't be in the next few years at least.

> > Again I'd have the CONFIG_SMP cover more.  The whole while loop and the
> > of_node_put.
> >
> However, here we still need to be able to check cpu node status and
> interrupt-server#s property, etc. for non-SMP (UP) systems as well,
> is it not? In that case, we can't really move the while loop inside the
> #ifdef SMP, can we?
> The case that you are talking about ( iterating  over the cpus and not doing
> anything ) would occur only in the case of a SMP machine running a UP
> kernel, is it not? That seems unlikely? Or are there other scenarios?

That would be an uncommon case, and performance is not critical.  I
would like to see such optimizations as a second patch after we have
moved the code and tested it.

Regards,
Paul.

** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/