linux-kernel - Re: [PATCH v2 2/2] locking/qrwlock: Don't contend with readers when setting _QW

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <557B6414.4080800@hp.com>
Date:	Fri, 12 Jun 2015 18:58:28 -0400
From:	Waiman Long <waiman.long@...com>
To:	Ingo Molnar <mingo@...nel.org>
CC:	Peter Zijlstra <peterz@...radead.org>,
	Ingo Molnar <mingo@...hat.com>, Arnd Bergmann <arnd@...db.de>,
	linux-arch@...r.kernel.org, linux-kernel@...r.kernel.org,
	Scott J Norton <scott.norton@...com>,
	Douglas Hatch <doug.hatch@...com>
Subject: Re: [PATCH v2 2/2] locking/qrwlock: Don't contend with readers when
 setting _QW_WAITING

On 06/12/2015 04:45 AM, Ingo Molnar wrote:
> * Waiman Long<waiman.long@...com>  wrote:
>
>>> Mind posting the microbenchmark?
>> I have attached the tool that I used for testing.
> Thanks, that's interesting!
>
> Btw., we could also do something like this in user-space, in tools/perf/bench/, we
> have no 'perf bench locking' subcommand yet.
>
> We already build and measure simple x86 kernel methods there such as memset() and
> memcpy():
>
>   triton:~/tip>  perf bench mem memcpy -r all
>   # Running 'mem/memcpy' benchmark:
>
>   Routine default (Default memcpy() provided by glibc)
>   # Copying 1MB Bytes ...
>
>         1.385195 GB/Sec
>         4.982462 GB/Sec (with prefault)
>
>   Routine x86-64-unrolled (unrolled memcpy() in arch/x86/lib/memcpy_64.S)
>   # Copying 1MB Bytes ...
>
>         1.627604 GB/Sec
>         5.336407 GB/Sec (with prefault)
>
>   Routine x86-64-movsq (movsq-based memcpy() in arch/x86/lib/memcpy_64.S)
>   # Copying 1MB Bytes ...
>
>         2.132233 GB/Sec
>         4.264465 GB/Sec (with prefault)
>
>   Routine x86-64-movsb (movsb-based memcpy() in arch/x86/lib/memcpy_64.S)
>   # Copying 1MB Bytes ...
>
>         1.490935 GB/Sec
>         7.128193 GB/Sec (with prefault)
>
> Locking primitives would certainly be more complex build in user-space - but we
> could shuffle things around in kernel headers as well to make it easier to test in
> user-space.
>
> That's how we can build lockdep in user-space for example, see tools/lib/lockdep.
>
> Just a thought.
>
> Thanks,
>
> 	Ingo

I guess we can build user-space version of spinlock and rwlock, but we 
can't do that for sleeping lock like mutex and rwsem. Preemption in user 
space will also affect how those locking test will behave. Anyway, I 
will give it a thought on how to do that in perf bench when I have time.

Cheers,
Longman
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/