On 5/7/2014 5:33 AM, Davidlohr Bueso wrote:
On Tue, 2014-05-06 at 12:29 +0200, Peter Zijlstra wrote:
So you forgot to CC Linus, Linus has expressed some dislike for
preemptible mmu_notifiers in the recent past:
https://lkml.org/lkml/2013/9/30/385
I'm glad this came up again.
So I've been running benchmarks (mostly aim7, which nicely exercises our
locks) comparing my recent v4 for rwsem optimistic spinning against
previous implementation ideas for the anon-vma lock, mostly:
- rwsem (currently)
- rwlock_t
- qrwlock_t
- rwsem+optspin
Of course, *any* change provides significant improvement in throughput
for several workloads, by avoiding to block -- there are more
performance numbers in the different patches. This is fairly obvious.
What is perhaps not so obvious is that rwsem+optimistic spinning beats
all others, including the improved qrwlock from Waiman and Peter. This
is mostly because of the idea of cancelable MCS, which was mimic'ed from
mutexes. The delta in most cases is around +10-15%, which is non
trivial.
These are great news David!
I mention this because from a performance PoV, we'll stop caring so much
about the type of lock we require in the notifier related code. So while
this is not conclusive, I'm not as opposed to keeping the locks blocking
as I once was. Now this might still imply things like poor design
choices, but that's neither here nor there.
So is the rwsem+opt strategy the way to go Given it keeps everyone happy?
We will be more than satisfied with it as it will allow us to guarantee
device
MMU update.
/me sees Sagi smiling ;)
:)
Sagi.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>