Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp2145129rwb; Thu, 17 Nov 2022 07:08:06 -0800 (PST) X-Google-Smtp-Source: AA0mqf49JqkY1TAJUFWv8J59wGWfWnmm1eELlH49cNY5+p5x1F5acHGNm2k+1fifEIEykH29EI33 X-Received: by 2002:aa7:c0da:0:b0:450:fb10:fdec with SMTP id j26-20020aa7c0da000000b00450fb10fdecmr2488621edp.339.1668697685877; Thu, 17 Nov 2022 07:08:05 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1668697685; cv=none; d=google.com; s=arc-20160816; b=QhVjgu2JTFwXLxb2RjPJc0wE+FXqCr1kCrqbkvLTkFPdWisp0m/HqYomfX/FcSmmIH hOVbojqPi+PyfktnzZIMBumo6iBkIMlUed7i4W0J6oSO2J9Q8eHmQkis1pxciAzBOopu XuYqpPVNT+V2muVxXTZ66BcGF2r6aa69GYZTc03lNilW2If3za+Wr9S9kYXMF1ERHfkE 9HxZtS4mDhGsgbbsT72e4S3CVr/6rys57I5mq31QmWj3utzS8B0wjBH49NQoEiMCaG1d oW8I+98xthsf/NLEX3WhwdTnJ+rcnubY0DUEroqogW61kPGiGx2XphHNyqZsHdTFOc3h MuGw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:dkim-signature; bh=8gmgQPGvV0Pdco46Use918rHcFMun1FBq8lcqpGuipk=; b=dFUb+/77WaPMXGn1CIGDfUPWu12GsH5Zvxh5f/3mbaejfzaPL4qHwQzH5Z8Mq6Ok7P nYRfLiFjyebQq138/3TmAaf0jShmmD1s1CEa7T0r91W9nYu8k7K/PZAR/BtoATQ4erv2 FQDVSQEQzHjNLlEM8s0+H67VnkXYdIEMid961VcyrgEZxeqY8pu1MgG56+jFLIqTxuUy NW1IwJ+xgXwfRmFl3Dyq5tfvWjymh4t4ifzrvS2AmjvdYF+oLz3svMLkCG0bbj+W3iPm JlANg9aLr5nozpU5LTzVPxmTh3wNJfK/AOaDhjin5AzU+DyhtSrBr+0/4SvrpRus54RQ +f5g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=WHLp+j2J; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id g10-20020a170906538a00b00782539a0286si616420ejo.142.2022.11.17.07.07.42; Thu, 17 Nov 2022 07:08:05 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=WHLp+j2J; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239923AbiKQOqk (ORCPT + 92 others); Thu, 17 Nov 2022 09:46:40 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42064 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234949AbiKQOqh (ORCPT ); Thu, 17 Nov 2022 09:46:37 -0500 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E237673BA8 for ; Thu, 17 Nov 2022 06:45:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1668696338; 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: in-reply-to:in-reply-to:references:references; bh=8gmgQPGvV0Pdco46Use918rHcFMun1FBq8lcqpGuipk=; b=WHLp+j2JwA+WtR97vTkPT0o4n4Tn8Z+CdeXCE+SjRo090Dnff4bI5Zw0Wgmn2367z/o2A/ T34RXjDWMNql3epTmt/hPbAJtxWid97jiX7oFRf1NnIylNSN4bSxhprZiLhAM0wUOy8upu vP4iCUt8Y6LZ+v5NwmINmfujQRfd8Ac= Received: from mail-wr1-f69.google.com (mail-wr1-f69.google.com [209.85.221.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-22-FEL6dEePPhi7tdj6RAbQBQ-1; Thu, 17 Nov 2022 09:45:36 -0500 X-MC-Unique: FEL6dEePPhi7tdj6RAbQBQ-1 Received: by mail-wr1-f69.google.com with SMTP id j30-20020adfa55e000000b00241b49be1a3so787485wrb.4 for ; Thu, 17 Nov 2022 06:45:36 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=8gmgQPGvV0Pdco46Use918rHcFMun1FBq8lcqpGuipk=; b=Nxj9XfhTADZz0UgtZ455Imh/TST+e77LbDmAyNoMiG5CEkezv8FzQbYKM2umfPvqv9 nzWukqxX38g5+j1P10o1vMqGVggbLj7w59DwQNSs59LGYdZsqQqTfTcDgnHkoHWrAhsV r/sLV2mWOHxDDGz542p0DSSYPqiLTQEkwDhRR2N1Y6yVfaWNODPrELO/MMX2L2UXI0/3 J0dJMJ/O4+tDkaAtlXs8ISuDTUJYxs53fkoaQyZ1kRrJ8L+lXPXTn4H+9SqQLph27XuA Yve5+4y6EvoUm0BKPOtsR+xNCfHxEhzbPanj7nF3TEF6nrN8vGT7rnqL7NO/SGgfrAoy bYxg== X-Gm-Message-State: ANoB5pl5vGGSamCCebTuvIFF/7s67QZR6ZPc9KFzSFyctszkBd3tLHvV dKiJopsHlz/SrJfv+lS9M9QxgxOREgRc3/bXqiNf69QnevtLdP6ZNYP16Kj00FO5w5u6TRzpIJN ayDbZ2Oin7bwLERR88NlgUnXN X-Received: by 2002:a5d:4683:0:b0:23a:43b7:cdd5 with SMTP id u3-20020a5d4683000000b0023a43b7cdd5mr1645401wrq.387.1668696335638; Thu, 17 Nov 2022 06:45:35 -0800 (PST) X-Received: by 2002:a5d:4683:0:b0:23a:43b7:cdd5 with SMTP id u3-20020a5d4683000000b0023a43b7cdd5mr1645351wrq.387.1668696335309; Thu, 17 Nov 2022 06:45:35 -0800 (PST) Received: from vschneid.remote.csb ([154.57.232.159]) by smtp.gmail.com with ESMTPSA id t18-20020a5d6a52000000b00236740c6e6fsm1069950wrw.100.2022.11.17.06.45.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 17 Nov 2022 06:45:34 -0800 (PST) From: Valentin Schneider To: Peter Zijlstra Cc: linux-alpha@vger.kernel.org, linux-kernel@vger.kernel.org, linux-snps-arc@lists.infradead.org, linux-arm-kernel@lists.infradead.org, linux-csky@vger.kernel.org, linux-hexagon@vger.kernel.org, linux-ia64@vger.kernel.org, loongarch@lists.linux.dev, linux-mips@vger.kernel.org, openrisc@lists.librecores.org, linux-parisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-riscv@lists.infradead.org, linux-s390@vger.kernel.org, linux-sh@vger.kernel.org, sparclinux@vger.kernel.org, linux-xtensa@linux-xtensa.org, x86@kernel.org, "Paul E. McKenney" , Steven Rostedt , Thomas Gleixner , Sebastian Andrzej Siewior , Juri Lelli , Daniel Bristot de Oliveira , Marcelo Tosatti , Frederic Weisbecker , Ingo Molnar , Borislav Petkov , Dave Hansen , "H. Peter Anvin" , Marc Zyngier , Mark Rutland , Russell King , Nicholas Piggin , Guo Ren , "David S. Miller" Subject: Re: [RFC PATCH v2 8/8] sched, smp: Trace smp callback causing an IPI In-Reply-To: References: <20221102182949.3119584-1-vschneid@redhat.com> <20221102183336.3120536-7-vschneid@redhat.com> Date: Thu, 17 Nov 2022 14:45:29 +0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 17/11/22 15:12, Peter Zijlstra wrote: > On Wed, Nov 02, 2022 at 06:33:36PM +0000, Valentin Schneider wrote: > *yuck* :-) > > How about something like so? > > --- > --- a/kernel/irq_work.c > +++ b/kernel/irq_work.c > @@ -24,6 +24,8 @@ > > #include > > +#include "sched/smp.h" > + > static DEFINE_PER_CPU(struct llist_head, raised_list); > static DEFINE_PER_CPU(struct llist_head, lazy_list); > static DEFINE_PER_CPU(struct task_struct *, irq_workd); > --- a/kernel/sched/core.c > +++ b/kernel/sched/core.c > @@ -3763,16 +3763,17 @@ void sched_ttwu_pending(void *arg) > rq_unlock_irqrestore(rq, &rf); > } > > -void send_call_function_single_ipi(int cpu) > +bool send_call_function_single_ipi(int cpu) > { > struct rq *rq = cpu_rq(cpu); > > if (!set_nr_if_polling(rq->idle)) { > - trace_ipi_send_cpumask(cpumask_of(cpu), _RET_IP_, NULL); > arch_send_call_function_single_ipi(cpu); > - } else { > - trace_sched_wake_idle_without_ipi(cpu); > + return true; > } > + > + trace_sched_wake_idle_without_ipi(cpu); > + return false; > } > > /* > --- a/kernel/sched/smp.h > +++ b/kernel/sched/smp.h > @@ -6,7 +6,7 @@ > > extern void sched_ttwu_pending(void *arg); > > -extern void send_call_function_single_ipi(int cpu); > +extern bool send_call_function_single_ipi(int cpu); > > #ifdef CONFIG_SMP > extern void flush_smp_call_function_queue(void); > --- a/kernel/smp.c > +++ b/kernel/smp.c > @@ -163,7 +163,6 @@ void __init call_function_init(void) > static inline void > send_call_function_ipi_mask(const struct cpumask *mask) > { > - trace_ipi_send_cpumask(mask, _RET_IP_, func); > arch_send_call_function_ipi_mask(mask); > } > > @@ -438,11 +437,16 @@ static void __smp_call_single_queue_debu > struct cfd_seq_local *seq = this_cpu_ptr(&cfd_seq_local); > struct call_function_data *cfd = this_cpu_ptr(&cfd_data); > struct cfd_percpu *pcpu = per_cpu_ptr(cfd->pcpu, cpu); > + struct __call_single_data *csd; > + > + csd = container_of(node, call_single_data_t, node.llist); > + WARN_ON_ONCE(!(CSD_TYPE(csd) & (CSD_TYPE_SYNC | CSD_TYPE_ASYNC))); > > cfd_seq_store(pcpu->seq_queue, this_cpu, cpu, CFD_SEQ_QUEUE); > if (llist_add(node, &per_cpu(call_single_queue, cpu))) { > cfd_seq_store(pcpu->seq_ipi, this_cpu, cpu, CFD_SEQ_IPI); > cfd_seq_store(seq->ping, this_cpu, cpu, CFD_SEQ_PING); > + trace_ipi_send_cpumask(cpumask_of(cpu), _RET_IP_, csd->func); > send_call_function_single_ipi(cpu); > cfd_seq_store(seq->pinged, this_cpu, cpu, CFD_SEQ_PINGED); > } else { > @@ -487,6 +491,27 @@ static __always_inline void csd_unlock(s > > static DEFINE_PER_CPU_SHARED_ALIGNED(call_single_data_t, csd_data); > > +static __always_inline > +bool raw_smp_call_single_queue(int cpu, struct llist_node *node) > +{ > + /* > + * The list addition should be visible to the target CPU when it pops > + * the head of the list to pull the entry off it in the IPI handler > + * because of normal cache coherency rules implied by the underlying > + * llist ops. > + * > + * If IPIs can go out of order to the cache coherency protocol > + * in an architecture, sufficient synchronisation should be added > + * to arch code to make it appear to obey cache coherency WRT > + * locking and barrier primitives. Generic code isn't really > + * equipped to do the right thing... > + */ > + if (llist_add(node, &per_cpu(call_single_queue, cpu))) > + return send_call_function_single_ipi(cpu); > + > + return false; > +} > + > void __smp_call_single_queue(int cpu, struct llist_node *node) > { > #ifdef CONFIG_CSD_LOCK_WAIT_DEBUG > @@ -503,19 +528,28 @@ void __smp_call_single_queue(int cpu, st > #endif > > /* > - * The list addition should be visible to the target CPU when it pops > - * the head of the list to pull the entry off it in the IPI handler > - * because of normal cache coherency rules implied by the underlying > - * llist ops. > - * > - * If IPIs can go out of order to the cache coherency protocol > - * in an architecture, sufficient synchronisation should be added > - * to arch code to make it appear to obey cache coherency WRT > - * locking and barrier primitives. Generic code isn't really > - * equipped to do the right thing... > - */ > - if (llist_add(node, &per_cpu(call_single_queue, cpu))) > - send_call_function_single_ipi(cpu); > + * We have to check the type of the CSD before queueing it, because > + * once queued it can have its flags cleared by > + * flush_smp_call_function_queue() > + * even if we haven't sent the smp_call IPI yet (e.g. the stopper > + * executes migration_cpu_stop() on the remote CPU). > + */ > + if (trace_ipi_send_cpumask_enabled()) { > + call_single_data_t *csd; > + smp_call_func_t func; > + > + csd = container_of(node, call_single_data_t, node.llist); > + > + func = sched_ttwu_pending; > + if (CSD_TYPE(csd) != CSD_TYPE_TTWU) > + func = csd->func; > + > + if (raw_smp_call_single_queue(cpu, node)) > + trace_ipi_send_cpumask(cpumask_of(cpu), _RET_IP_, func); So I went with the tracepoint being placed *before* the actual IPI gets sent to have a somewhat sane ordering between trace_ipi_send_cpumask() and e.g. trace_call_function_single_entry(). Packaging the call_single_queue logic makes the code less horrible, but it does mix up the event ordering... > + return; > + } > + > + raw_smp_call_single_queue(cpu, node); > } > > /* > @@ -983,10 +1017,13 @@ static void smp_call_function_many_cond( > * number of CPUs might be zero due to concurrent changes to the > * provided mask. > */ > - if (nr_cpus == 1) > + if (nr_cpus == 1) { > + trace_ipi_send_cpumask(cpumask_of(last_cpu), _RET_IP_, func); > send_call_function_single_ipi(last_cpu); This'll yield an IPI event even if no IPI is sent due to the idle task polling, no? > - else if (likely(nr_cpus > 1)) > - send_call_function_ipi_mask(cfd->cpumask_ipi); > + } else if (likely(nr_cpus > 1)) { > + trace_ipi_send_cpumask(mask, _RET_IP_, func); > + send_call_function_ipi_mask(mask); > + } > > cfd_seq_store(this_cpu_ptr(&cfd_seq_local)->pinged, this_cpu, CFD_SEQ_NOCPU, CFD_SEQ_PINGED); > }