Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp9313249imu; Wed, 5 Dec 2018 02:45:28 -0800 (PST) X-Google-Smtp-Source: AFSGD/XtoCWtINSNwJCXSDZRwNUmSAduYI0q5CpKmf3yiju9D6M3K0hE+2mMfq+yogTpKBCouzSz X-Received: by 2002:a62:d005:: with SMTP id p5mr15567864pfg.175.1544006728395; Wed, 05 Dec 2018 02:45:28 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1544006728; cv=none; d=google.com; s=arc-20160816; b=nLl9uILYrpQutKHc6BKqYG6Q9HxeTWDnUTcZinYjhH3pILP9Oi4yK0pc1JAqQ14/Iv CH5q/jH1U5U1u+N9GW3iyT8EANetMxPnMdJT+z3yisx4UM+qsGXqlupFxtEYYv4n6zQl f+iHbdAdfPZA+O7fJIlUUtFxW89MF/zdoE2lV0W0zLLgJkhm1qfDvTaJohhGaLLILYix T4McISTNQ5ISEgGN7xZ8UNk1y2wnw7ut2Z8rbX9wtSV/yVK/tcQvaXzHNE1uORaZi5i7 zZ0geJrme86G6HE410RoxXrkZhePoV6oT1cssEI9kgipq477mEG+AboJt3s0BRGJUxgn RU6w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=HRI4PDsEEwb31m3DRLBEFs4W8LJyus7kckexdrC0sas=; b=t88D5568+LHzeUNLSKXTMOY0FfqPBW2pOGU4zwXwTS1C3nPcHMgrzSkTvEsnHaOwas V/pvMNM4FE82hmWyh7b+JilePoCZ4NGpNKO6hiZoX+Kz+Xao1ib6Q/FOP+Xr6G2TqPl1 IERRK2VhcenrkEOnBUmaF88ja/Z4yUC1ZKirIxws5hLuHDWZ5J5wS7JLzRHlZO6cU6DM b+FW5MC9T1BWoJzOkdIri3vEM8Wi8HGdMeD3/4Nu759Yc3f1X40KpSPgWNFZejSF3nKm qRrKrGGPzX6zbljVUjyjsAGi2HzjAN2UQC+aqeswhYt4hfePJd8E8d4w27pMw7PQm6Vl /m6w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=Lyap9fIF; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m8si17797869pgd.555.2018.12.05.02.45.13; Wed, 05 Dec 2018 02:45:28 -0800 (PST) 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; dkim=pass header.i=@linaro.org header.s=google header.b=Lyap9fIF; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727452AbeLEKn0 (ORCPT + 99 others); Wed, 5 Dec 2018 05:43:26 -0500 Received: from mail-yb1-f193.google.com ([209.85.219.193]:33569 "EHLO mail-yb1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726171AbeLEKnZ (ORCPT ); Wed, 5 Dec 2018 05:43:25 -0500 Received: by mail-yb1-f193.google.com with SMTP id f125so3452227ybc.0 for ; Wed, 05 Dec 2018 02:43:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HRI4PDsEEwb31m3DRLBEFs4W8LJyus7kckexdrC0sas=; b=Lyap9fIFpvmPqItvXQ5xgdadbnM7zJTCd8BWpLSob4VHaBroFebRDaUUR8UoP2OsCk BX4SvFENr1cwLKkCUVfqVFoUKq8D+yDLDTt3KjYSzE5t2rkcMlW1WIJZr9Kjxyy2/zXw 6YUeQuDQ7myfwD8dyQxhUu1amM6guzeog98VE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=HRI4PDsEEwb31m3DRLBEFs4W8LJyus7kckexdrC0sas=; b=MEtXJOu/2N2Xx/G1w6UXBrl5j10MKjk0A14rNDW5bQGrRmjI4ajT5EB8U+9tSi+0zg qT8WQuFi9PCSqbI1iPHzoNmmt/s2Sge6AOumApHi9idYYlD8WiMpUBwt3vaLScw1WVc2 y/Rul0vKvtjd5IT5VWJ+qwXpeXmxxZA26AdRzAg0kRxZDEcTQAI9K//BDE8DCe9Ql4rB 8nOHx/x84CzTs9dWaJYgkLHn6pXvAnRWPF/iX0QbDBMquQ1BvR63Mi/cWWSexFHU6rdD 76cvfMSvecnb1Yzj5cMroz8V0k8ZN3By0m+uawjTDH5OzMq1IlwbPxx8xEh+x0JekcQH b03g== X-Gm-Message-State: AA+aEWZw8YAvgRQfxKrpyt+shci6g77FwiTBuf6bsn0EVb25yJuGG2xG 1EKHb8tjAPNmu2UsX2vDUV/Abe2zsa704XoGARN/ZQ== X-Received: by 2002:a25:1143:: with SMTP id 64-v6mr22413321ybr.195.1544006604364; Wed, 05 Dec 2018 02:43:24 -0800 (PST) MIME-Version: 1.0 References: <20181204192903.8193-1-anders.roxell@linaro.org> <20181205095445.GA14317@arm.com> In-Reply-To: <20181205095445.GA14317@arm.com> From: Anders Roxell Date: Wed, 5 Dec 2018 11:43:12 +0100 Message-ID: Subject: Re: [PATCH v2] tracing: add cond_resched to ftrace_replace_code() To: Will Deacon Cc: rostedt@goodmis.org, mingo@redhat.com, Catalin Marinas , Kees Cook , Arnd Bergmann , Linux Kernel Mailing List , Linux ARM Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 5 Dec 2018 at 10:54, Will Deacon wrote: > > Hi Anders, Steve, > > On Tue, Dec 04, 2018 at 08:29:03PM +0100, Anders Roxell wrote: > > When running in qemu on an kernel built with allmodconfig and debug > > options (in particular kcov and ubsan) enabled, ftrace_replace_code > > function call take minutes. The ftrace selftest calls > > ftrace_replace_code to look >40000 through > > ftrace_make_call/ftrace_make_nop, and these end up calling > > __aarch64_insn_write/aarch64_insn_patch_text_nosync. > > > > Microseconds add up because this is called in a loop for each dyn_ftrace > > record, and this triggers the softlockup watchdog unless we let it sleep > > occasionally. > > > > Rework so that we call cond_resched() if !irqs_disabled() && !preempt_count(). > > > > Suggested-by: Steven Rostedt (VMware) > > Signed-off-by: Anders Roxell > > --- > > kernel/trace/ftrace.c | 10 ++++++++++ > > 1 file changed, 10 insertions(+) > > > > diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c > > index c375e33239f7..7080eb464983 100644 > > --- a/kernel/trace/ftrace.c > > +++ b/kernel/trace/ftrace.c > > @@ -2419,11 +2419,19 @@ void __weak ftrace_replace_code(int enable) > > { > > struct dyn_ftrace *rec; > > struct ftrace_page *pg; > > + bool schedulable; > > int failed; > > > > if (unlikely(ftrace_disabled)) > > return; > > > > + /* > > + * Some archs calls this function with interrupts or preemption > > + * disabled. However, for other archs that can preempt, this can cause > > + * an tremendous unneeded latency. > > + */ > > + schedulable = !irqs_disabled() && !preempt_count(); > > Is there a reason not to use preemptible() here? As I understand it preemptible() is defined to 0 if CONFIG_PREEMPT_COUNT is disabled. Thats no good right ? Cheers, Anders