Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754783AbcKUPVl (ORCPT ); Mon, 21 Nov 2016 10:21:41 -0500 Received: from foss.arm.com ([217.140.101.70]:34604 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753934AbcKUPVk (ORCPT ); Mon, 21 Nov 2016 10:21:40 -0500 Subject: Re: spin_lock behavior with ARM64 big.Little/HMP To: Vikram Mulukutla References: <400ab4b8b2354c5b9283f6ed657363a0@codeaurora.org> <8d9d6333-0ebe-65c4-c6f1-3e3475e3e535@arm.com> Cc: Sudeep Holla , Catalin Marinas , Will Deacon , linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel-owner@vger.kernel.org From: Sudeep Holla Organization: ARM Message-ID: Date: Mon, 21 Nov 2016 15:21:36 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; 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: 1369 Lines: 53 On 18/11/16 20:22, Vikram Mulukutla wrote: > > Hi Sudeep, > > Thanks for taking a look! > > On 2016-11-18 02:30, Sudeep Holla wrote: >> Hi Vikram, >> >> On 18/11/16 02:22, Vikram Mulukutla wrote: >>> Hello, >>> >>> This isn't really a bug report, but just a description of a >>> frequency/IPC >>> dependent behavior that I'm curious if we should worry about. The >>> behavior >>> is exposed by questionable design so I'm leaning towards don't-care. >>> >>> Consider these threads running in parallel on two ARM64 CPUs running >>> mainline >>> Linux: >>> >> >> Are you seeing this behavior with the mainline kernel on any platforms >> as we have a sort of workaround for this ? >> > > If I understand that workaround correctly, the ARM timer event stream is > used > to periodically wake up CPUs that are waiting in WFE, is that right? I > think > my scenario below may be different because LittleCPU doesn't actually wait > on a WFE event in the loop that is trying to increment lock->next, i.e. > it's > stuck in the following loop: > > ARM64_LSE_ATOMIC_INSN( > /* LL/SC */ > " prfm pstl1strm, %3\n" > "1: ldaxr %w0, %3\n" > " add %w1, %w0, %w5\n" > " stxr %w2, %w1, %3\n" > " cbnz %w2, 1b\n", > Interesting. Just curious if this is r0p0/p1 A53 ? If so, is the errata 819472 enabled ? -- Regards, Sudeep