> -----Original Message----- > From: Sasha Levin [mailto:levinsasha928@xxxxxxxxx] > Sent: Wednesday, August 17, 2011 8:48 AM > To: KY Srinivasan > Cc: gregkh@xxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; > devel@xxxxxxxxxxxxxxxxxxxxxx; virtualization@xxxxxxxxxxxxxx; Haiyang Zhang > Subject: Re: [PATCH 2/8] Staging: hv: vmbus: Invoke vmbus_on_msg_dpc() > directly > > On Mon, 2011-08-15 at 15:12 -0700, K. Y. Srinivasan wrote: > > The message processing function needs to execute on the same CPU where > > the interrupt was taken. tasklets cannot gurantee this; so, invoke the > > function directly. > > > > Signed-off-by: K. Y. Srinivasan <kys@xxxxxxxxxxxxx> > > Signed-off-by: Haiyang Zhang <haiyangz@xxxxxxxxxxxxx> > > --- > > tasklets are guaranteed to run on the same CPU as the function that > scheduled them. > > Unless I'm missing something? I too was under this impression until I stumbled upon this comment in include/Linux/interrupt.h where I see that there is no guarantee that tasklet would run on the same CPU that it was scheduled on (look at the first listed property): /* Tasklets --- multithreaded analogue of BHs. Main feature differing them of generic softirqs: tasklet is running only on one CPU simultaneously. Main feature differing them of BHs: different tasklets may be run simultaneously on different CPUs. Properties: * If tasklet_schedule() is called, then tasklet is guaranteed to be executed on some cpu at least once after this. . . */ Given this comment here, I felt that safest thing to do would be to just not use the tasklet in this scenario. Regards, K. Y _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
