> -----Original Message----- > From: John Garry <john.g.garry@xxxxxxxxxx> > Sent: Wednesday, August 9, 2023 9:02 PM > To: Nilesh Javali <njavali@xxxxxxxxxxx>; martin.petersen@xxxxxxxxxx > Cc: linux-scsi@xxxxxxxxxxxxxxx; GR-QLogic-Storage-Upstream <GR-QLogic- > Storage-Upstream@xxxxxxxxxxx>; Anil Gurumurthy > <agurumurthy@xxxxxxxxxxx>; Shreyas Deodhar <sdeodhar@xxxxxxxxxxx> > Subject: Re: [EXT] Re: [PATCH v2 07/10] qla2xxx: Observed call trace in > smp_processor_id() > > On 09/08/2023 07:03, Nilesh Javali wrote: > >> Furthermore, for the instance where the calltrace is reported, above, > >> there is no mention of why it is indeed safe to use > >> raw_smp_processor_id() and why the warning from smp_processor_id() can > >> be ignored. > >> > > Thanks for the review. > > > > This patch aims to silent the warning message in case > CONFIG_DEBUG_PREEMPT is turned on by > > any user reporting an issue. > > For qla2xxx driver it is not critical to have accurate CPU ID which would > momentarily cause > > performance hit for the thread that pre-empted. > > I doubt that the driver needs to check the current CPU so often, if at > all. But I don't know the driver well, so can't say more. > > Apart from that, according to description of queue_work(): > "We queue the work to the CPU on which it was submitted, but if the CPU > dies it can be processed by another CPU." > > So isn't something like > queue_work_on(raw_smp_processor_id(), ha->wq, &qpair->q_work) same as > queue_work(ha->wq, &qpair->q_work)? > > I see that queue_work() already has the raw_smp_processor_id() call. In fact queue_work uses queue_work_on that has raw_smp_processor_id. So, qla2x using queue_work_on with raw_smp_processor_id should be okay, unless you think otherwise. Thanks, Nilesh
