Re: 2.6.11-rc1-mm1

[Robert Wisniewski]

Christoph Hellwig writes:
 > On Sun, Jan 16, 2005 at 03:11:00PM -0500, Robert Wisniewski wrote:
 > > int global_val;
 > > 
 > > modify_val_spin()
 > > {
 > > 	acquire_spin_lock()
 > > 	// calculate some_value based on global_val
 > > 	// for example c=global_val; if (c%0) some_value=10; else some_value=20;
 > > 	global_val = global_val + some_value
 > > 	release_spin_lock()
 > > }
 > > 
 > > modify_val_atomic()
 > > {
 > > 	do
 > > 	// calculate some_value based on global_val
 > > 	// for example c=global_val; if (c%0) some_value=10; else some_value=20;
 > > 	global_val = global_val + some_value
 > > 	while (compare_and_store(global_val, , ))
 > > }
 > > 
 > > What's the difference.  The deal is if two processes execute this code
 > > simultaneously and one gets interrupted in the middle of modify_val_spin,
 > > then the other wastes its entire quantum spinning for the lock.  In the
 > > modify_val_atomic if one process gets interrupted, no problem, the other
 > > process can proceed through, then when the first one runs again the CAS
 > > will fail, and it will go around the loop again.  Now imagine it was the
 > > kernel involved...
 > 
 > Just prevent that with spin_lock_irq.  But anyway this example doesn't
 > fit the ltt code.  cmpxchg loops can make lots of sense for such simple
 > loops, but as soon as you need to do significant work in the loop it
 > starts to get problematic.  Your example would btw be better off using

The loop in question is where we grab the current (old) index, perform a
computation (or three).  The only expensive operation is the timestamp
acquisition which has been modified to use the cheaper rtsc, so I still
think that's within the realm of a reasonably simply loop.  I think what
you want to avoid is starting to walk a (potentially indeterminate) data
structure in such atomic op loop.

 > atomic_t and it's primitives so you abstract away the actual implementation
 > and the architecture can chose the most efficient implementation.
 > 

That's an interesting thought because it might address Andrew's concern.
We'll investigate.  Thanks.

-bob

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/