Hi George, everyone,
I noticed this issue while going through the scheduling code. Basically,
for the runq debugkey, locking happens in schedule.c (which we usually
don't want) and doesn't seem take credit2's runqs<-->CPUs mapping into
account.
I think this patch correctly deals with locking in this specific case,
but of course I'm happy to hear what you think! :-)
I tested the patch with all schedulers, but as you can imagine it's
quite hard to produce an actual race and see if it is being handled
properly...
Thanks and Regards,
Dario
--
<<This happens because I choose it to happen!>> (Raistlin Majere)
-------------------------------------------------------------------
Dario Faggioli, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
PhD Candidate, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa (Italy)
I noticed this issue while going through the scheduling code. Basically,
for the runq debugkey, locking happens in schedule.c (which we usually
don't want) and doesn't seem take credit2's runqs<-->CPUs mapping into
account.
I think this patch correctly deals with locking in this specific case,
but of course I'm happy to hear what you think! :-)
I tested the patch with all schedulers, but as you can imagine it's
quite hard to produce an actual race and see if it is being handled
properly...
Thanks and Regards,
Dario
--
<<This happens because I choose it to happen!>> (Raistlin Majere)
-------------------------------------------------------------------
Dario Faggioli, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
PhD Candidate, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa (Italy)