From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753303AbcHZNIG (ORCPT ); Fri, 26 Aug 2016 09:08:06 -0400 Received: from foss.arm.com ([217.140.101.70]:39105 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753028AbcHZNIF (ORCPT ); Fri, 26 Aug 2016 09:08:05 -0400 Subject: Re: [PATCH v2 9/9] arm64: Work around systems with mismatched cache line sizes To: Ard Biesheuvel References: <1472203398-8751-1-git-send-email-suzuki.poulose@arm.com> <1472203398-8751-10-git-send-email-suzuki.poulose@arm.com> Cc: Will Deacon , Catalin Marinas , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" , Marc Zyngier , Mark Rutland , Andre Przywara From: Suzuki K Poulose Message-ID: Date: Fri, 26 Aug 2016 14:08:01 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 26/08/16 14:04, Suzuki K Poulose wrote: > On 26/08/16 12:03, Ard Biesheuvel wrote: >> Hello Suzuki, >> > > >>> For faster access (i.e, avoiding to lookup the system wide value of CTR_EL0 >>> via read_system_reg), we keep track of the pointer to table entry for >>> CTR_EL0 in the CPU feature infrastructure. >>> >> >> IIUC it is the runtime sorting of the arm64_ftr_reg array that >> requires you to stash a pointer to CTR_EL0's entry somewhere, so that >> you can dereference it without doing the bsearch. > > Correct. > >> >> IMO, this is a pattern that we should avoid: you are introducing one >> instance now, which will make it hard to say no to the next one in the >> future. Isn't there a better way to organize the arm64_ftr_reg array >> that allows us to reference entries directly? Ideally, a way that gets >> rid of the runtime sorting, since I don't think that is a good >> replacement for developer discipline anyway (although I should have >> spoken up when that was first introduced) Or am I missing something >> here? > > I had some form of direct access to the feature register in one of > the versions [0], but was dropped based on Catalin's suggestion at [1]. Forgot to add, [0] wouldn't solve this issue cleanly either. It would simply speed up the read_system_reg(). So we do need a call to read_system_reg() from assembly code, which makes it a little bit tricky. Suzuki > > > [0] https://lkml.org/lkml/2015/10/5/504 > [1] https://lkml.org/lkml/2015/10/7/558 > > > Suzuki > >