linux-kernel - Re: [PATCH 3/3] locking/rwsem: Scan the wait

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: <20160806060541.GA20695@gmail.com>
Date:	Sat, 6 Aug 2016 08:05:41 +0200
From:	Ingo Molnar <mingo@...nel.org>
To:	Davidlohr Bueso <dave@...olabs.net>
Cc:	peterz@...radead.org, Waiman.Long@...com, jason.low2@....com,
	wanpeng.li@...mail.com, linux-kernel@...r.kernel.org,
	Davidlohr Bueso <dbueso@...e.de>
Subject: Re: [PATCH 3/3] locking/rwsem: Scan the wait_list for readers only
 once


* Davidlohr Bueso <dave@...olabs.net> wrote:

> When wanting to wakeup readers, __rwsem_mark_wakeup() currently
> iterates the wait_list twice while looking to wakeup the first N
> queued reader-tasks. While this can be quite inefficient, it was
> there such that a awoken reader would be first and foremost
> acknowledged by the lock counter.
> 
> Keeping the same logic, we can further benefit from the use of
> wake_qs and avoid entirely the first wait_list iteration that sets
> the counter as wake_up_process() isn't going to occur right away,
> and therefore we maintain the counter->list order of going about
> things.
> 
> Other than saving cycles with O(n) "scanning", this change also
> nicely cleans up a good chunk of __rwsem_mark_wakeup(); both
> visually and less tedious to read.
> 
> For example, the following improvements where seen on some will
> it scale microbenchmarks, on a 48-core Haswell:
> 
>                                      v4.7              v4.7-rwsem-v1
> Hmean    signal1-processes-8    5792691.42 (  0.00%)  5771971.04 ( -0.36%)
> Hmean    signal1-processes-12   6081199.96 (  0.00%)  6072174.38 ( -0.15%)
> Hmean    signal1-processes-21   3071137.71 (  0.00%)  3041336.72 ( -0.97%)
> Hmean    signal1-processes-48   3712039.98 (  0.00%)  3708113.59 ( -0.11%)
> Hmean    signal1-processes-79   4464573.45 (  0.00%)  4682798.66 (  4.89%)
> Hmean    signal1-processes-110  4486842.01 (  0.00%)  4633781.71 (  3.27%)
> Hmean    signal1-processes-141  4611816.83 (  0.00%)  4692725.38 (  1.75%)
> Hmean    signal1-processes-172  4638157.05 (  0.00%)  4714387.86 (  1.64%)
> Hmean    signal1-processes-203  4465077.80 (  0.00%)  4690348.07 (  5.05%)
> Hmean    signal1-processes-224  4410433.74 (  0.00%)  4687534.43 (  6.28%)

Please always make it clear in changelogs what the numbers mean, that higher 
numbers are better, etc. - so that people don't have to re-read it 2-3 times to 
figure out what it means.

Also, what are 'will it scale microbenchmarks'?

Thanks,

	Ingo