> > I can only think of a 'lazy' approach to setting channel CPU affinity: > > we actually re-assign it to the target CPU when we receive first > > interrupt there - but it's not very different from re-assigning it there > > but still handling interrupts on the old CPU like you do. > > Interesting! I'm wondering whether it'd make sense to use a similar > approach to (lazily) "unblock" the "old" CPUs; let me think more... So, I spent some more time thinking about this... AFAICT, one main issue with this approach (besides the fact that we'd need to "save" the "old" CPUs...) is that we might be blocking that CPU for "too long" (depending on the channel/device usage); also, this approach seemed to make the handling of target_cpu a bit more involved, and this is a concern considered that (as mentioned before) we'd like to keep the target_cpu of *all* channels in the system balanced. I'm sticking to the approach implemented here for now: I'm planning to send a new version of the series with minor changes soon. Thanks, Andrea
