Re: [RFC] Heterogeneous memory management (mirror process address space on a device mmu).

[sagi grimberg <sagig@mellanox.com>]

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@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>