linux-kernel - Re: [PATCH v2] bit_spinlock: introduce smp_cond_load

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: <dedbc211-082b-be4a-1bce-2593084d4ca3@huawei.com>
Date:   Tue, 6 Nov 2018 19:36:41 +0800
From:   Gao Xiang <gaoxiang25@...wei.com>
To:     Peter Zijlstra <peterz@...radead.org>
CC:     Will Deacon <will.deacon@....com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Philippe Ombredanne <pombredanne@...b.com>,
        Kate Stewart <kstewart@...uxfoundation.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        <linux-kernel@...r.kernel.org>, Miao Xie <miaoxie@...wei.com>,
        Chao Yu <chao@...nel.org>
Subject: Re: [PATCH v2] bit_spinlock: introduce smp_cond_load_relaxed

Hi Peter,

On 2018/11/6 19:00, Peter Zijlstra wrote:
>>> Yes, that's much better. Ideally though, we'd get rid of bit spinlocks
>>> that have significant enough contention for this to matter.
>> OK, I will send v3 to fix like the above.
> That's not answering the full question though. What bit spinlocks did
> you find where this matters? And can't we convert them to proper
> spinlocks instead?

I just misunderstood your question and I get your point now.

"What bit spinlocks did you find where this matters?" nope..I said the original
background to Greg before, that is I tried to use smp_cond_load_relaxed instead
of busy spining in the development of erofs file system and I saw this bit_spinlock
implementation by chance...This is not a big modification but since I raised the
question before and I want to trace to the end...

"And can't we convert them to proper spinlocks instead?" I think bit_spinlock is
sometime preferred since it requires little memory and can be integrated into some
fields(eg. flags)...It is selectable for spinlocks don't have to many users
at the same time, so I think it depends on the detailed real use scenerio...
It is just a tool for user code to select case by case... That is my personal idea...

IMO, to use wrapped up function for the detailed scenario could be better than
open-coded all the time (eg. do cpu_relax(); while(...)) since it could be
optimizated even more for the specific architecture...

Thanks,
Gao Xiang