In fact, right now, we read it at every iteration of the loop. The reason it's done like this is how context switch was handled on IA64 (see commit ae9bfcdc, "[XEN] Various softirq cleanups" [1]).
However: 1) we don't have IA64 any longer, and all the achitectures that we do support, are ok with sampling once and for all; 2) sampling at every iteration (slightly) affect performance; 3) sampling at every iteration is misleading, as it makes people believe that it is currently possible that SCHEDULE_SOFTIRQ moves the execution flow on another CPU (and the comment, by reinforcing this belief, makes things even worse!). Therefore, let's: - do the sampling once and for all, and remove the comment; - leave an ASSERT() around, so that, if context switching logic changes (in current or new arches), we will notice. [1] Some more (historical) information here: http://old-list-archives.xenproject.org/archives/html/xen-devel/2006-06/msg01262.html Signed-off-by: Dario Faggioli <dario.faggi...@citrix.com> --- Cc: Andrew Cooper <andrew.coop...@citrix.com> Cc: George Dunlap <george.dun...@eu.citrix.com> Cc: Jan Beulich <jbeul...@suse.com> Cc: Konrad Rzeszutek Wilk <konrad.w...@oracle.com> Cc: Stefano Stabellini <sstabell...@kernel.org> Cc: Julien Grall <julien.gr...@arm.com> Cc: Tim Deegan <t...@xen.org> --- xen/common/softirq.c | 8 ++------ 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/xen/common/softirq.c b/xen/common/softirq.c index ac12cf8..67c84ba 100644 --- a/xen/common/softirq.c +++ b/xen/common/softirq.c @@ -27,16 +27,12 @@ static DEFINE_PER_CPU(unsigned int, batching); static void __do_softirq(unsigned long ignore_mask) { - unsigned int i, cpu; + unsigned int i, cpu = smp_processor_id(); unsigned long pending; for ( ; ; ) { - /* - * Initialise @cpu on every iteration: SCHEDULE_SOFTIRQ may move - * us to another processor. - */ - cpu = smp_processor_id(); + ASSERT(cpu == smp_processor_id()); if ( rcu_pending(cpu) ) rcu_check_callbacks(cpu); _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel