On 11/20/2015 08:39 PM, Thomas Gleixner wrote:
Same applies when doing the reverse mapping.
In other words, the ipi_mask won't always necessarily be linear to facilitate
the 1:1 mapping that this approach assumes.
It is a solvable problem, but I think we're losing the elegance that promoted
going into this direction and I think sticking to using struct ipi_mapping
(with some enhancements to how it's exposed an integrated by/into generic
code) is a better approach.
The only reason to use the ipi_mapping thing is if we need non
consecutive masks, i.e. cpu 5 and 9.
That's the case I had in mind.
I really don't want to have it mandatory as it does not make any sense
for systems where the IPI is a single per_cpu interrupt. For the
linear consecutive space it is just adding memory and cache footprint
for no benefit. Think about machines with 4k and more cpus ....
OK. Although so far I think the ovehead is higher without the
ipi_mapping because of all the extra checkings we have to do when
sending an IPI. I'll leave this to code review when I have something
ready though.
I'm debugging more problems and hopefully I'll send something this week.
Thanks,
Qais
