Received: by 2002:a25:868d:0:0:0:0:0 with SMTP id z13csp665129ybk; Wed, 13 May 2020 09:48:13 -0700 (PDT) X-Google-Smtp-Source: ABdhPJygEaggosl7cItTcR2w8uBM6LU4JkxydGdH1FTC7cCgk1Me7C0Csc4hgg3yMTroSCrElgPT X-Received: by 2002:a05:6402:1d23:: with SMTP id dh3mr496583edb.349.1589388492801; Wed, 13 May 2020 09:48:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1589388492; cv=none; d=google.com; s=arc-20160816; b=LE8kGJG3kDZbUF5hn5XMMPom4xxnxxlp49DJrQEIir2j853IW/bgGYwL4iv6a9cliX m6CoTLg20M9a+MCLTA94Gl2a/IybtcYumynrrXB0541J+5aoaqK1KpU4/DmMsyP1bAqH q+VA5/+ZKUOevbh+6PeWeYi/E5VikkEHpD9fsfbkEkhV725WL6vMXX29kUk98fDw/qT4 wxjCA4iTkUk67w9UWQstHM428x+9QkNMEgbwUK5sc7DwvkFNxdlW7BvM3KPBx93EUXU0 gteTb3rjSFNpO0mFR1eX2BrEBI7NlnAq5Wjcb2Z1aBz56Qgti9KGHilvKDaiB1DYVj5h 4p1w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from; bh=nbEP7wcADinfPKC3elXcaYSNx0a0sDnUfMZs7vJKmrA=; b=u9UQA0rZnCCUpq2h/BPoeBMIOcdvvIgdz1GQsg53/sEzPRoZr33UeuLLGNvAQJcD/W xMLYtHAip3f91kSTI7qGP01UZFy1E80sCsaIZnt+mBedDaeVG2poMM2u+XQEXOR6DmKe 8Z2Thjm6QjNkpwnVcUfActVOsTVvEaasI7tgMQ6hA7b+fTYWWsr6BMRK0LHQhriAuWcq /OjGY6BASaiCf0lso79l8JvejLnVv6mqP9JANTqzCFi0H+WHafBhnchY9OZC5zuTONF5 hKzqxfN2ncSOTXvFiqHzIFcYPz/B0hU+oqG0w3iEeABpaVp4wu9Di446AncTi2SSmM6y 7y5w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id j23si164289eja.168.2020.05.13.09.47.49; Wed, 13 May 2020 09:48:12 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732662AbgEMQnl (ORCPT + 99 others); Wed, 13 May 2020 12:43:41 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57510 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728354AbgEMQnl (ORCPT ); Wed, 13 May 2020 12:43:41 -0400 Received: from Galois.linutronix.de (Galois.linutronix.de [IPv6:2a0a:51c0:0:12e:550::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1AA41C061A0C for ; Wed, 13 May 2020 09:43:41 -0700 (PDT) Received: from p5de0bf0b.dip0.t-ipconnect.de ([93.224.191.11] helo=nanos.tec.linutronix.de) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1jYuTl-0000gE-KR; Wed, 13 May 2020 18:43:33 +0200 Received: by nanos.tec.linutronix.de (Postfix, from userid 1000) id 067AE100605; Wed, 13 May 2020 18:43:32 +0200 (CEST) From: Thomas Gleixner To: Wojciech Kudla , linux-kernel@vger.kernel.org Cc: mingo@redhat.com, hpa@zytor.com, x86@kernel.org, Steven Rostedt , Will Deacon Subject: Re: x86/smp: adding new trace points In-Reply-To: References: <4d54953b-f968-63f5-569f-9e09bc0f361c@gmail.com> <87y2pw2fav.fsf@nanos.tec.linutronix.de> Date: Wed, 13 May 2020 18:43:32 +0200 Message-ID: <87sgg323bf.fsf@nanos.tec.linutronix.de> MIME-Version: 1.0 Content-Type: text/plain 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 Wojciech Kudla writes: > On 13/05/2020 13:24, Thomas Gleixner wrote: > >> Why would the SMP call function single interrupt go through the >> PLATFORM_IPI_VECTOR? It goes as the name says through the >> CALL_FUNCTION_SINGLE_VECTOR. >> > > Wrong vector, my bad. > > However 2) still stands in my opinion. We don't have "ipi raise" trace > point for x86. RESCHEDULE_VECTOR, CALL_FUNCTION_SINGLE_VECTOR, as > well as TLB invalidation vectors are essentially > inter-processor-interrupts if I'm not mistaken. Would a patch adding > such trace point be considered here? Maybe. Though that IPI tracing is inconsistent across architectures. I'm not really interested to have yet another x86 variant which is slightly different than anything else. ARM and ARM64 share generic tracepoints for that, though the actual tracepoint invocation is in the architecture specific code. If at all we really want to have the common IPIs which are required for SMP support covered by generic tracepoints and have them in the generic code and not sprinkled all over arch/* Thanks, tglx