Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756625AbbLDWsT (ORCPT ); Fri, 4 Dec 2015 17:48:19 -0500 Received: from g2t4622.austin.hp.com ([15.73.212.79]:44888 "EHLO g2t4622.austin.hp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752705AbbLDWsS (ORCPT ); Fri, 4 Dec 2015 17:48:18 -0500 Message-ID: <5662182E.4050909@hpe.com> Date: Fri, 04 Dec 2015 17:48:14 -0500 From: Waiman Long User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.12) Gecko/20130109 Thunderbird/10.0.12 MIME-Version: 1.0 To: Linus Torvalds CC: Peter Zijlstra , Will Deacon , Ingo Molnar , Oleg Nesterov , Linux Kernel Mailing List , Paul McKenney , Boqun Feng , Jonathan Corbet , Michal Hocko , David Howells , Paul Turner Subject: Re: [PATCH 3/4] locking: Introduce smp_cond_acquire() References: <20151203124010.627312076@infradead.org> <20151203124339.552838970@infradead.org> <20151203163725.GJ11337@arm.com> <20151203202627.GV17308@twins.programming.kicks-ass.net> <5661FCD0.60909@hpe.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1752 Lines: 51 On 12/04/2015 05:05 PM, Linus Torvalds wrote: > On Fri, Dec 4, 2015 at 12:51 PM, Waiman Long wrote: >> Will the following work? > Are we trying to win some obfuscated C contest here? > > Just make it do something like (skipping backslashes to make it easier > to type and read) > > #define smp_cond_load_acquire(ptr, cond_expr) ({ > typeof(*ptr) VAL; > for (;;) { > VAL = READ_ONCE(*ptr); > if (cond_expr) break; > cpu_relax(); > } > smp_rmb(); > VAL; > }) > > and then you'd have it be > > val = smp_cond_load_acquire(&lock->val.counter, > !(VAL& _Q_LOCKED_PENDING_MASK)); > > which is at least halfway legible. Not some odd "fragments of > expressions" interfaces unless absolutely required, please. It is just some random thought that I have. I am not saying that it is the right way to go. > Of course, I suspect we should not use READ_ONCE(), but some > architecture-overridable version that just defaults to READ_ONCE(). > Same goes for that "smp_rmb()". Because maybe some architectures will > just prefer an explicit acquire, and I suspect we do *not* want > architectures having to recreate and override that crazy loop. > > How much does this all actually end up mattering, btw? > > Linus I think what Will want to do is to provide an architecture specific replacement for the whole macro, not just part of it. So using READ_ONCE should be fine. Cheers, Longman -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/