From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751001AbcGNHpS (ORCPT ); Thu, 14 Jul 2016 03:45:18 -0400 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:4439 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1750829AbcGNHpM (ORCPT ); Thu, 14 Jul 2016 03:45:12 -0400 X-IBM-Helo: d28dlp01.in.ibm.com X-IBM-MailFrom: xinhui.pan@linux.vnet.ibm.com X-IBM-RcptTo: linux-arch@vger.kernel.org;linux-kernel@vger.kernel.org Date: Thu, 14 Jul 2016 15:44:42 +0800 From: xinhui User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: Peter Zijlstra CC: linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, mingo@redhat.com, arnd@arndb.de, Waiman.Long@hpe.com Subject: Re: [PATCH v3] locking/qrwlock: Let qrwlock has same layout regardless of the endian References: <1466403652-2931-1-git-send-email-xinhui.pan@linux.vnet.ibm.com> <20160713195423.GD30921@twins.programming.kicks-ass.net> In-Reply-To: <20160713195423.GD30921@twins.programming.kicks-ass.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 16071407-0008-0000-0000-000002E15341 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 16071407-0009-0000-0000-00000E1E79BB Message-Id: <578742EA.7060108@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-07-14_04:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1607140085 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2016年07月14日 03:54, Peter Zijlstra wrote: > On Mon, Jun 20, 2016 at 02:20:52PM +0800, Pan Xinhui wrote: >> This patch aims to get rid of endianness in queued_write_unlock(). We >> want to set __qrwlock->wmode to NULL, however the address is not >> &lock->cnts in big endian machine. That causes queued_write_unlock() >> write NULL to the wrong field of __qrwlock. >> >> Actually qrwlock can have same layout, IOW we can remove the #if >> __little_endian in struct __qrwlock. With such modification, we only >> need define some _QW* and _QR* with corresponding values in different >> endian systems. >> >> Suggested-by: Will Deacon >> Signed-off-by: Pan Xinhui >> Acked-by: Waiman Long >> --- > > Urgh, I hate this stuff :/ > > OK, so I poked at this a bit and I ended up with the below; but now > qrwlock and qspinlock are inconsistent; although I suspect qspinlock is > similarly busted wrt endian muck. > > Not sure what to do.. > Lets talk about the qspinlock. for x86, We has already assumed that ->locked sit at the low 8 bits, as is smp_store_release((u8 *)lock, 0); Then we can do a favor, export ->locked but other fields as reserved. say struct __qspinlock_unlcok_interface {/* what name is better?*/ #ifdef __LITTLE_ENDIAN u8 locked; u8 reserved[3]; /* do not touch it, internally use only */ #else u8 reserved[3]; u8 locked; #endif }; I think it is acceptable. and we can do similar things with qrwlock, too. any thoughts? > /* > - * Writer states & reader shift and bias > + * Writer states & reader shift and bias. > + * > + * | +0 | +1 | +2 | +3 | > + * ----+----+----+----+----+ > + * LE | 12 | 34 | 56 | 78 | 0x12345678 > + * ----+----+----+----+----+ > + * BE | 78 | 56 | 34 | 12 | 0x12345678 > + * ----+----+----+----+----+ > + * | wr | rd | > + * +----+----+----+----+ > + * > */ very clearly. :) thanks xinhui