From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.3 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B83F0C2D0DB for ; Fri, 24 Jan 2020 15:19:45 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 4C35420709 for ; Fri, 24 Jan 2020 15:19:45 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="YXYgQ6vm"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="GD5lam+o" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4C35420709 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date: Message-ID:References:To:From:Subject:Reply-To:Content-ID:Content-Description :Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=LRZm8Rg/x7xoylZzCOKkxTXy1n/MIMtPpuzjncr0RNg=; b=YXYgQ6vmmBuW97 FnuQzaZ/G28JssN9bCym9F7j6V9CU1aJ8LV/QOKu5JPAbym0FaUULE3Fn0xm5rYh73bEIYfnuS3eI HG+NJaDiJ8ss3C55xq2tRU++60GrYoVIxpmwV2MhGPiaPZ5KVjN3ZHZxwBwgg4iI7L31hhjoNDG9M gSTTILqBhzRa21BOYWsHeKnmkbYwAeQQ2gn4ikq1A7RT22NRyM85nBrmkS7CrTzU3GvirdD9LZsNN /QFa40V2N3lzAdj76zBMpDuv0/zyChREN0+O0Ip5EntjnVkA17LidQWdSUVsJoBMDQhPJQeXiOfHP LR+w3X5dh4DoyB92YqcA==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1iv0kH-0001kj-Tk; Fri, 24 Jan 2020 15:19:41 +0000 Received: from us-smtp-2.mimecast.com ([207.211.31.81] helo=us-smtp-delivery-1.mimecast.com) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1iv0kE-0001jp-Su for linux-arm-kernel@lists.infradead.org; Fri, 24 Jan 2020 15:19:40 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1579879172; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=CjNxeMNsGavEdY38q63l/ayJZ7osKKaCqYNvfelv++c=; b=GD5lam+oWlfmveLusPgeGdMzqivHRQo0V41Ntgjx2MhgS2f0Hd6UFyizha1/oUZYSRxVxm eKak6cn+9ZQuOwZGiVvB0djPZmQpsaZamfqQZV5UMHfJriYVyrn33s/QU0bzsxsW6kzFEB caPrnxlyQCZBrs3SqIleosPd4yt2Bo4= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-297-Ps6EiY_oNriTufej_AH0jA-1; Fri, 24 Jan 2020 10:19:28 -0500 X-MC-Unique: Ps6EiY_oNriTufej_AH0jA-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 1844B19218ED; Fri, 24 Jan 2020 15:19:20 +0000 (UTC) Received: from llong.remote.csb (ovpn-124-92.rdu2.redhat.com [10.10.124.92]) by smtp.corp.redhat.com (Postfix) with ESMTP id 9FC5D84D90; Fri, 24 Jan 2020 15:19:13 +0000 (UTC) Subject: Re: [PATCH v8 4/5] locking/qspinlock: Introduce starvation avoidance into CNA From: Waiman Long To: Peter Zijlstra , Alex Kogan 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> Organization: Red Hat Message-ID: <48ce49e5-98a7-23cd-09f4-8290a65abbb5@redhat.com> Date: Fri, 24 Jan 2020 10:19:14 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: <2c6741c5-d89d-4b2c-cebe-a7c7f6eed884@redhat.com> Content-Language: en-US X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200124_071939_012661_4B5CF770 X-CRM114-Status: GOOD ( 18.16 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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, Steven Sistare , Thomas Gleixner , Daniel Jordan , linux-arm-kernel Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 1/24/20 9:42 AM, Waiman Long wrote: > On 1/24/20 2:52 AM, Peter Zijlstra wrote: >> On Thu, Jan 23, 2020 at 04:33:54PM -0500, Alex Kogan wrote: >>> Let me put this question to you. What do you think the number should be? >> I think it would be very good to keep the inter-node latency below 1ms. > It is hard to guarantee that given that lock hold times can vary quite a > lot depending on the workload. What we can control is just how many > later lock waiters can jump ahead before a given waiter. >> But to realize that we need data on the lock hold times. Specifically >> for the heavily contended locks that make CNA worth it in the first >> place. >> >> I don't see that data, so I don't see how we can argue about this let >> alone call something reasonable. >> > In essence, CNA lock is for improving throughput on NUMA machines at the > expense of increasing worst case latency. If low latency is important, > it should be disabled. If CONFIG_PREEMPT_RT is on, > CONFIG_NUMA_AWARE_SPINLOCKS should be off. Actually, what we are worrying about is the additional latency that can be added to important tasks or execution contexts that are waiting for a lock. Maybe we can make CNA lock behaves somewhat like qrwlock is that requests from interrupt context are giving priority. We could add a priority flag in the CNA node. If the flag is set, we will never put it into the secondary queue. In fact, we can transfer control next to it even if it is not on the same node. We may also set the priority flag if it is a RT task that is trying to acquire the lock. In this way, we can guarantee that important tasks or contexts will not suffer a delay in acquiring the lock. Those less important tasks, however, may need to wait a bit longer before they can get the lock. What do you guys think about that? Regards, Longman _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel