Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp7348125imu; Mon, 3 Dec 2018 11:23:13 -0800 (PST) X-Google-Smtp-Source: AFSGD/WoA0p6lbQVBK7eQKZEPVEbmOE2mDfMdKsIk/IrjCQo+wkT1l9S2es0zn9yFsQH9XVax5dR X-Received: by 2002:a17:902:b707:: with SMTP id d7mr8387327pls.29.1543864993631; Mon, 03 Dec 2018 11:23:13 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1543864993; cv=none; d=google.com; s=arc-20160816; b=EjVtaKRWyyd7hYCrX8FNCnzLrWVJkeuD3AGGY2RpiV4jjSZTphIboDNVVmpdPFWgM2 +pFwbyNz3TKrCV4kttbyHPwu/YV4243D+IAlNVqC8udKi3XOwFNobjwTBCFCkrkjosVo O0fk2T28zaY0nBgqnKWYHyMK90Hf5wD74ACLxnV4zW1shEgAncOJQ7uikGbNFIdQB46u zoGekx7lZFtuM+83wNAdaYmBxtu810wmzVJF08x3B44oFar2O52oSs0dio3yWdx+fyIw VcBpQD2wABh+juGjn6xJvsQuHfLwvSjEsm1udr7xmjgVWDa6pcknramgVbey9v4EKilf 5NRQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=g0jV+L3iBe+zckxuqEe8W5FO+Ltcj2mGNmA/FhzyB1Y=; b=rbWH7GKY2FFM2Mkz88Ep12yKLIqDtVGncbdnrhAigmmQ/rtN4BmO9WKfQOGdhQfwd/ fzme2lD7Njc9av+KGbEoHokUbcLVKZ2skFmgialG/JpwCYZi7U8ZrnWJ7ADULyqo9K3I IWHmWRwaG3vlgcS+wZ9u7dvOLGWc3ujYbIf/v75NmlXDDFW0Ls2OiBtJ9TYKCmyTf2NU 5eAQUv28Zy2Pcl5/A+3p2Ag1jv9+qVOOQHzbizhqb6wBrgBWDpSQm5PLKfRBo6xRS/xR 0m7j6TSY4I2v0FrJ5VhahYIE0sDh/zRmUgHM/jwqCQSwNFwMzvYGpXmiaVgCSdiSx+iO s6TA== 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 w31si15312620pla.308.2018.12.03.11.22.57; Mon, 03 Dec 2018 11:23:13 -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; 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 S1725952AbeLCTWN (ORCPT + 99 others); Mon, 3 Dec 2018 14:22:13 -0500 Received: from foss.arm.com ([217.140.101.70]:45916 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725850AbeLCTWN (ORCPT ); Mon, 3 Dec 2018 14:22:13 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id F3B9E1688; Mon, 3 Dec 2018 11:22:08 -0800 (PST) Received: from edgewater-inn.cambridge.arm.com (usa-sjc-imap-foss1.foss.arm.com [10.72.51.249]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id C3DDC3F575; Mon, 3 Dec 2018 11:22:08 -0800 (PST) Received: by edgewater-inn.cambridge.arm.com (Postfix, from userid 1000) id CE1721AE1062; Mon, 3 Dec 2018 19:22:28 +0000 (GMT) Date: Mon, 3 Dec 2018 19:22:28 +0000 From: Will Deacon To: Anders Roxell Cc: rostedt@goodmis.org, mingo@redhat.com, catalin.marinas@arm.com, keescook@chromium.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Arnd Bergmann Subject: Re: [PATCH 3/3] arm64: ftrace: add cond_resched() to func ftrace_make_(call|nop) Message-ID: <20181203192228.GC29028@arm.com> References: <20181130150956.27620-1-anders.roxell@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20181130150956.27620-1-anders.roxell@linaro.org> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Anders, On Fri, Nov 30, 2018 at 04:09:56PM +0100, Anders Roxell wrote: > Both of those functions end up calling ftrace_modify_code(), which is > expensive because it changes the page tables and flush caches. > 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() before going into the > ftrace_modify_code() function. > > Co-developed-by: Arnd Bergmann > Signed-off-by: Arnd Bergmann > Signed-off-by: Anders Roxell > --- > arch/arm64/kernel/ftrace.c | 10 ++++++++++ > 1 file changed, 10 insertions(+) It sounds like you're running into issues with the existing code, but I'd like to understand a bit more about exactly what you're seeing. Which part of the ftrace patching is proving to be expensive? The page table manipulation only happens once per module when using PLTs, and the cache maintenance is just a single line per patch site without an IPI. Is it the loop in ftrace_replace_code() that is causing the hassle? Will