Received: by 10.213.65.68 with SMTP id h4csp721181imn; Fri, 23 Mar 2018 14:29:09 -0700 (PDT) X-Google-Smtp-Source: AG47ELv1SykdY3awhuyi+6j+AiyOhOMFGdB9KyKSw1hngjCMFa1wHqqqDIUxjkwLSYCXKzmkJpPq X-Received: by 10.99.183.15 with SMTP id t15mr22547113pgf.416.1521840549372; Fri, 23 Mar 2018 14:29:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521840549; cv=none; d=google.com; s=arc-20160816; b=sti2t2xP5JYz6Ts0QPXd2uKy1LMIqpi4gpBdul6VbZqvgDD9ure/FlyZTi96OK94NM 9bNX6f5+8OnDHKf/oXQb1zDcDcOicoc1Y44u/+4BoraXRH7s7TI3Kb+5BTlp1xNSBoHw 2nYxc0QSSwlfc2yV9J9A2pEltn9Jn8SE1lOEg7qWZ7VyCgGNdFGIwmW6Dh5acnJeQToi 4ne2E0NTHwkcTwmezHkKNxu/IVTHaMYXD91Ixscrg9PngcTbYT5E7rl/kkwyJ2XtYhMX bzIspCPN3tXh1/HyxlETRi3zRH8jfg8wUIkNQj92smFipWyMCbszjq7Lp/VH/5x53hAJ YGfA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date :arc-authentication-results; bh=iW6k7Oqhx0ggSiN9tJGgNt4VBHgqPwe3i5cIzMqcask=; b=FGHyx0uXtbFbSzj5VKBP1DhUEYKsNzH3FAngywRo/5O41PvEyEmlX8p5QcJEidkXMr PDUZ4Ko2wDSdSxLQXzDHDyKYLBh1a5MMvDKvDDf3V9wwD+7s/5rPMGX5EgXfB7OMP3/x oTc3UDhCCVi31eHvKqFY9bXzVkqhypG3f+xxjoK0lft7ZbFX77MF3jwS+VqtEXdhwAQP jhhTZ1UT1oEGuGsakJA8PM9h3KUH80GRvF8J2zLLXCYRDyDiQjBOg4Em1W9AlGDikuXT +YDKp18iSQQdX1BaKFeN6fSUmE2+zmEGsf0MTVQqa3qtJWoYN2dmJwnLZ+9GWCRt2jjX d8AA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id z5-v6si9101962plo.727.2018.03.23.14.28.54; Fri, 23 Mar 2018 14:29:09 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752098AbeCWV1z (ORCPT + 99 others); Fri, 23 Mar 2018 17:27:55 -0400 Received: from Galois.linutronix.de ([146.0.238.70]:42399 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751713AbeCWV1y (ORCPT ); Fri, 23 Mar 2018 17:27:54 -0400 Received: from p4fea5f09.dip0.t-ipconnect.de ([79.234.95.9] helo=nanos.glx-home) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1ezUE4-0003JQ-4B; Fri, 23 Mar 2018 22:27:52 +0100 Date: Fri, 23 Mar 2018 22:27:51 +0100 (CET) From: Thomas Gleixner To: Eric Dumazet cc: x86 , lkml , Eric Dumazet , "H. Peter Anvin" , Ingo Molnar , Hugh Dickins , Borislav Petkov Subject: Re: [PATCH v2 1/2] x86, msr: add rdmsr_safe_on_cpu_resched() and use it in msr_read() In-Reply-To: <20180319152503.123372-1-edumazet@google.com> Message-ID: References: <20180319152503.123372-1-edumazet@google.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 19 Mar 2018, Eric Dumazet wrote: > I noticed high latencies caused by a daemon periodically reading > various MSR on all cpus. KASAN kernels would see ~10ms latencies > simply reading one MSR. Even without KASAN, sending IPI to CPU > in deep sleep state or blocking hard IRQ in a a long section, > then waiting for the answer can consume hundreds of usec. > > This patch adds rdmsr_safe_on_cpu_resched() which does not spin. > > I use this function from msr_read() but future patches might > convert other callers to use this variant as well. > > Overall daemon cpu usage was reduced by 35 %, > and latencies caused by msr_read() disappeared. Looking at all call sites. None of them is performance critical and all of them are in preemptible context. So we simply can switch the rdmsr_safe_on_cpu() implementation over to wait mode completely. > +/* Note: This version spins in smp_call_function_single(). > + * Consider using rdmsr_safe_on_cpu_resched() variant instead. Bah. This is not networking code. x86 uses sensible comment style :) Thanks, tglx