Thread (11 messages) 11 messages, 5 authors, 2013-10-01

Re: Avoiding the dentry d_lock on final dput(), part deux: transactional memory

From: Paul E. McKenney <hidden>
Date: 2013-10-01 13:42:52
Also in: linux-fsdevel, lkml

On Tue, Oct 01, 2013 at 05:16:54AM -0700, Paul E. McKenney wrote:
On Tue, Oct 01, 2013 at 02:52:28PM +1000, Michael Neuling wrote:
quoted
quoted
quoted
Well we don't have to, I think Mikey wasn't totally clear about that
"making all registers volatile" business :-) This is just something we
need to handle in assembly if we are going to reclaim the suspended
transaction.
Yeah, sorry.  The slow path with all registers as volatile is only
needed if we get pre-empted during the transaction.
quoted
quoted
So basically, what we need is something along the lines of
enable_kernel_tm() which checks if there's a suspended user transaction
and if yes, kills/reclaims it.

Then we also need to handle in our interrupt handlers that we have an
active/suspended transaction from a kernel state, which we don't deal
with at this point, and do whatever has to be done to kill it... we
might get away with something simple if we can state that we only allow
kernel transactions at task level and not from interrupt/softirq
contexts, at least initially.
Call me a coward, but this is starting to sound a bit scary.  ;-)
We are just wanting to prototype it for now to see if we could make it
go faster.  If it's worth it, then we'd consider the additional
complexity this would bring.

I don't think it'll be that bad, but I'd certainly want to make sure
it's worth it before trying :-)
OK, fair point.  ;-)
That is, a fair point -assuming- that we also try the memory-barrier-free
cmpxchg that Linus suggested...

							Thanx, Paul
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help