On Wed, Feb 7, 2024 at 6:25 PM Björn Töpel <bjorn@xxxxxxxxxx> wrote: > > Björn Töpel <bjorn@xxxxxxxxxx> writes: > > >>> Hmm, seems like we're talking past each other, or at least I get the > >>> feeling I can't get my opinions out right. I'll try to do a quick PoC, > >>> to show you what I mean. That's probably easier than just talking about > >>> it. ...and maybe I'll come realizing I'm all wrong! > >> > >> I suggest to wait for my v13 and try something on top of that > >> otherwise we might duplicate efforts. > > > > OK! > > I did some really rough code sketching, and I'm confident that you can > get rid of all ids_enabled_bitmap, hwirqs_used_bitmap, and the > corresponding functions/locks. I'd say one lock is enough, and the key > is having the per-cpu imsic_local_priv.vectors change from struct > imsic_vector * to struct imsic_vector **. I have managed to remove hwirqs_bitmap (and related function). Now, I am trying another approach to simplify locking using atomics. > > Using smp_call_function_single() to IPI enable (and disable if you don't > want to use the lazy timer disable mechanism) seems feasible as well! We have intentionally kept separate virq for synchronization because this allows us to gather stats for debugging. Calling smp_call_function_single() will not allow us to separately gather stats for sync IPIs. The smp_call_function_single() eventually leads to __ipi_send_mask() via send_ipi_mask() in arch/riscv so directly calling __ipi_send_mask() for sync IPI is faster. > > (Let me know if you don't have the spare cycles, and I can help out.) > > > Björn Regards, Anup
