Re: 2.6.11-rc1-mm1

[Robert Wisniewski]

Andrew Morton writes:
 > Robert Wisniewski <bob@xxxxxxxxxxxxxx> wrote:
 > >
 > > 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.
 > 
 > One could use spin_lock_irq().  The performance would be similar.

Yes on some architectures I think you right (on some archs though I'm not
so sure) - Ingo and I had that debate a bit ago.  But as you astutely noted
or asked below, the original intent was to be able to use a single shared
buffer for user and kernel space.  In fact, the lockless design of tracing
in K42, which motivated this design does that.  For a couple of reasons we
have not (yet?) done that for LTT.  But, for example, NPTL could have made
use of it when they were investigating a tracing facility.  Recently,
another company using LTT for device driver and video debugging is very
interested in cheap user space tracing in conjunction with kernel tracing
because they need both sets of events to understand what is up.  The debate
is still open for the best way to get cheap user space logging, but there
seems to be an increasing need for it by the community.

 > 
 > > Now imagine it was the kernel involved...
 > 
 > Or are you saying that userspace does the above as well?

:-) - as above.  Furthermore, it seems that reducing the places where
interrupts are disabled would be a good thing?  By not introducing
additional disable interrupts tracing has less of an impact.  I was also
pointing out Christoph's statement that spin locks and atomic ops are the
same is not accurate (except for perhaps limited cases, but then you must
make such arguments - not necessarily good), and we had good reasons for
using an atomic op.

Thanks.

-bob

Robert Wisniewski
The K42 MP OS Project
http://www.research.ibm.com/K42/
bob@xxxxxxxxxxxxxx
-
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/