From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter Zijlstra Subject: Re: [PATCH v8 4/5] locking/qspinlock: Introduce starvation avoidance into CNA Date: Sat, 25 Jan 2020 12:16:07 +0100 Message-ID: <20200125111607.GV11457@worktop.programming.kicks-ass.net> References: <20191230194042.67789-1-alex.kogan@oracle.com> <20191230194042.67789-5-alex.kogan@oracle.com> <20200121132949.GL14914@hirez.programming.kicks-ass.net> <3862F8A1-FF9B-40AD-A88E-2C0BA7AF6F58@oracle.com> <20200124075235.GX14914@hirez.programming.kicks-ass.net> <2c6741c5-d89d-4b2c-cebe-a7c7f6eed884@redhat.com> <48ce49e5-98a7-23cd-09f4-8290a65abbb5@redhat.com> <8D3AFB47-B595-418C-9568-08780DDC58FF@oracle.com> <714892cd-d96f-4d41-ae8b-d7b7642a6e3c@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <714892cd-d96f-4d41-ae8b-d7b7642a6e3c@redhat.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=m.gmane-mx.org@lists.infradead.org To: Waiman Long Cc: linux-arch@vger.kernel.org, Hanjun Guo , Arnd Bergmann , dave.dice@oracle.com, Jan Glauber , x86@kernel.org, Will Deacon , linux@armlinux.org.uk, linux-kernel@vger.kernel.org, Ingo Molnar , Borislav Petkov , hpa@zytor.com, Alex Kogan , Steven Sistare , Thomas Gleixner , Daniel Jordan , linux-arm-kernel List-Id: linux-arch.vger.kernel.org On Fri, Jan 24, 2020 at 11:46:53AM -0500, Waiman Long wrote: > I also thought about that. As you said, it can be hard to guarantee that > reliable time value can be retrieved in a timely manner across all the > archs. Rememer that this code is limited to 64bit archs that have NUMA, my quick grep says that is limited to: alpha, arm64, ia64, mips, powerpc, s390, sparc, x86 afaict, x86 is the one with the worst clocks between the lot of them (with exception of ia64, which has been completely buggered for a while and nobody cares). > Even if we can do that, we will introduce latency to important > tasks or contexts. I like the first approach better. In general, the kernel has no clues what is actually important. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bombadil.infradead.org ([198.137.202.133]:48402 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725767AbgAYLQp (ORCPT ); Sat, 25 Jan 2020 06:16:45 -0500 Date: Sat, 25 Jan 2020 12:16:07 +0100 From: Peter Zijlstra Subject: Re: [PATCH v8 4/5] locking/qspinlock: Introduce starvation avoidance into CNA Message-ID: <20200125111607.GV11457@worktop.programming.kicks-ass.net> References: <20191230194042.67789-1-alex.kogan@oracle.com> <20191230194042.67789-5-alex.kogan@oracle.com> <20200121132949.GL14914@hirez.programming.kicks-ass.net> <3862F8A1-FF9B-40AD-A88E-2C0BA7AF6F58@oracle.com> <20200124075235.GX14914@hirez.programming.kicks-ass.net> <2c6741c5-d89d-4b2c-cebe-a7c7f6eed884@redhat.com> <48ce49e5-98a7-23cd-09f4-8290a65abbb5@redhat.com> <8D3AFB47-B595-418C-9568-08780DDC58FF@oracle.com> <714892cd-d96f-4d41-ae8b-d7b7642a6e3c@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <714892cd-d96f-4d41-ae8b-d7b7642a6e3c@redhat.com> Sender: linux-arch-owner@vger.kernel.org List-ID: To: Waiman Long Cc: Alex Kogan , linux@armlinux.org.uk, Ingo Molnar , Will Deacon , Arnd Bergmann , linux-arch@vger.kernel.org, linux-arm-kernel , linux-kernel@vger.kernel.org, Thomas Gleixner , Borislav Petkov , hpa@zytor.com, x86@kernel.org, Hanjun Guo , Jan Glauber , Steven Sistare , Daniel Jordan , dave.dice@oracle.com Message-ID: <20200125111607.7NPD2V3aLCIwaDRZ9nMLBPCGgvqXjVnnZfdjJRZvddU@z> On Fri, Jan 24, 2020 at 11:46:53AM -0500, Waiman Long wrote: > I also thought about that. As you said, it can be hard to guarantee that > reliable time value can be retrieved in a timely manner across all the > archs. Rememer that this code is limited to 64bit archs that have NUMA, my quick grep says that is limited to: alpha, arm64, ia64, mips, powerpc, s390, sparc, x86 afaict, x86 is the one with the worst clocks between the lot of them (with exception of ia64, which has been completely buggered for a while and nobody cares). > Even if we can do that, we will introduce latency to important > tasks or contexts. I like the first approach better. In general, the kernel has no clues what is actually important.