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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

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.

/me sees Sagi smiling ;)

Thanks,
Davidlohr

--
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>




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]