On Fri, Apr 07, 2023 at 05:49:02PM -0700, Paul E. McKenney wrote: > On Fri, Apr 07, 2023 at 03:05:01PM +0200, Jonas Oberhauser wrote: > > > > > > On 4/7/2023 2:12 AM, Joel Fernandes wrote: > > > > > > > > > > On Apr 6, 2023, at 6:34 PM, Paul E. McKenney <paulmck@xxxxxxxxxx> wrote: > > > > > > > > On Thu, Apr 06, 2023 at 05:36:13PM -0400, Alan Stern wrote: > > > > > Paul: > > > > > > > > > > I just saw that two of the files in > > > > > tools/memory-model/litmus-tests have > > > > > almost identical names: > > > > > > > > > > Z6.0+pooncelock+pooncelock+pombonce.litmus > > > > > Z6.0+pooncelock+poonceLock+pombonce.litmus > > > > > > > > > > They differ only by a lower-case 'l' vs. a capital 'L'. It's > > > > > not at all > > > > > easy to see, and won't play well in case-insensitive filesystems. > > > > > > > > > > Should one of them be renamed? > > > > > > > > Quite possibly! > > > > > > > > The "L" denotes smp_mb__after_spinlock(). The only code difference > > > > between these is that Z6.0+pooncelock+poonceLock+pombonce.litmus has > > > > smp_mb__after_spinlock() and Z6.0+pooncelock+pooncelock+pombonce.litmus > > > > does not. > > > > > > > > Suggestions for a better name? We could capitalize all the letters > > > > in LOCK, I suppose... > > > > I don't think capitalizing LOCK is helpful. > > Greek font, then? (Sorry, couldn't resist...) > > > To be honest, almost all the names are extremely cryptic to newcomers like > > me (like, what does Z6.0 mean? Is it some magic incantation?). > > And that's not something that's easy to fix. > > All too true on all counts. Some of the names abbreviate the litmus > test itself, and there are multiple encodings depending one who/what > generated the test in question. Others of the names relate to who came > up with them or the code from which they are derived. > > New allegedly universal naming schemes have a rather short half-life. > > What would be cool would be a way to structurally compare litmus tests. > I bet that there are quite a few duplicates, for example. > > > The only use case I can think of for spending time improving the names is > > that sometimes you wanna say something like "oh, this is like > > Z6.0+pooncelock+pooncelockmb+pombonce". And then people can look up what > > that is. > > For that, it's important that the names are easy to disambiguate by humans, > > and I think Joel's suggestion is an improvement. > > (and it also fixes the issue brought up by Alan about case-insensitive file > > systems) > > > > > > > > Z6.0+pooncelock+pooncelockmb+pombonce.litmus ? > > I am OK with this one, but then again, I was also OK with the original > Z6.0+pooncelock+poonceLock+pombonce.litmus. ;-) FWIW, if I move that smp_mb_after..() a step lower, that also makes the test work (see below). If you may look over quickly my analysis of why this smp_mb_after..() is needed, it is because what I marked as a and d below don't have an hb relation right? (* b ->rf c d ->co e e ->hb f basically the issue is a ->po b ->rf c ->po d does not imply a ->hb d *) P0(int *x, int *y, spinlock_t *mylock) { spin_lock(mylock); WRITE_ONCE(*x, 1); // a WRITE_ONCE(*y, 1); // b spin_unlock(mylock); } P1(int *y, int *z, spinlock_t *mylock) { int r0; spin_lock(mylock); r0 = READ_ONCE(*y); // c smp_mb__after_spinlock(); // moving this a bit lower also works fwiw. WRITE_ONCE(*z, 1); // d spin_unlock(mylock); } P2(int *x, int *z) { int r1; WRITE_ONCE(*z, 2); // e smp_mb(); r1 = READ_ONCE(*x); // f } exists (1:r0=1 /\ z=2 /\ 2:r1=0) > Would someone like to to a "git mv" send the resulting patch? Yes I can do that in return as I am thankful in advance for the above discussion. ;) thanks, - Joel