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