* Mateusz Guzik <mjguzik@xxxxxxxxx> [250203 15:22]: > On Mon, Feb 3, 2025 at 9:14 PM Liam R. Howlett <Liam.Howlett@xxxxxxxxxx> wrote: > > > > * Mateusz Guzik <mjguzik@xxxxxxxxx> [250203 14:36]: > > > On Mon, Feb 3, 2025 at 8:27 PM Liam R. Howlett <Liam.Howlett@xxxxxxxxxx> wrote: > > > > > > > > * Mateusz Guzik <mjguzik@xxxxxxxxx> [250201 11:31]: > > > > > Signed-off-by: Mateusz Guzik <mjguzik@xxxxxxxxx> > > > > > > > > Change log is a bit sparse? I get that the subject spells out what is > > > > done, but anything to say here at all? Reduces lock contention by > > > > reducing lock time or something? Maybe even some numbers you have in > > > > the cover letter? > > > > > > > > > > I did not measure this bit *specifically*. > > > > > > As one can expect get_pid issues an atomic and that's slow. And since > > > it can happen *prior* to taking the global lock it seems like an > > > obvious little nit to sort out. > > > > > > I would argue the change is self-explanatory given the cover-letter. > > > > But when you git blame on the file, you will not see that cover letter. > > if this lands, I presume it is going to go through Andrew who uses > tooling pulling in the cover letter for each commit > > but i'm not going to argue this bit, just provide with a commit > message which you think works and I'll use it Your comment above states why this is beneficial. Why not use a variation of your statement of get_pid issuing an atomic which can be removed from the locking area? This seems like an important detail to capture. > > -- > Mateusz Guzik <mjguzik gmail.com>
