Received: by 2002:ac0:8845:0:0:0:0:0 with SMTP id g63csp499262img; Tue, 26 Feb 2019 03:55:22 -0800 (PST) X-Google-Smtp-Source: AHgI3IadEkKlI790RIeg8r6+G9EDpAjogR3Y9LJzn6UcoQAhA7Y/3xHTOVYQu+TUKNPXMl6qr640 X-Received: by 2002:a62:3990:: with SMTP id u16mr25674125pfj.80.1551182122485; Tue, 26 Feb 2019 03:55:22 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1551182122; cv=none; d=google.com; s=arc-20160816; b=Dh/TUiEDA7i9fzCeYkBwzq6YqOWqVRSkT0Uk+oisvdsiOwO3iFuBL2kqUMZv2Z77bc KghGj+2Z+jAldbl6LSRTva/WcD4Wb7QkNYYjcBnVH3bhpyuvRxkiYdCd9GjG5bww0b1v sKZTbesmYDCMUAAFiGTAhJ9+u0rELMq28ZBU7RNDa5RYDVYS6VKJD2BtrEvmeEi1zbW8 WYJA28NtSX+r+qBbbSND0rANpEyFhr0cKi6X2jBVqiHV9HPG6Z/zEzHis38HuU2Mwlpb e0c2Pb7zvXifjoQIMgX8Xt7PKw0FGT/VEe2/C15Sm/RcF6Ss7HBiUxIUj1FXy2DjkT6y Kk2A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=cGNNoK09CTDUyj2ud8QE5EPlLbn1UKYnweqcgtcw30c=; b=M4sG5DRw5fyPv4RW8waw/6wGGYFA4AfUZzAQSfOTyWtVjuUiTlAx2GbMa23Vu35EKb G1z0fM6rqacJ5nD6To2Qs/1e2QgXJznMPGxJ0FF49FUAaQc+H4amE8mcLMY4EUEX/UiB Cnzf+dnD+l9/5yrE9X8vARsiYsx0Dy2zUURpyBabYBlKNfvBcEn15AdsFhfY5tnyEeqf pcJ6IxukDpd10/KkEKBOT8B/4zzmdGAGqwWdVNLyqh1Z6+hOQ96GPgLk5yKtunLbRriN dT6Ij9PQ9lHV0XhT0o1RZek0lgMyknNHU/9TjkgLNb3ajeXnydR1rJJrNJkG7YjGs7Ai gBsA== 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 e125si13020718pfe.14.2019.02.26.03.55.07; Tue, 26 Feb 2019 03:55:22 -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 S1726561AbfBZLyM (ORCPT + 99 others); Tue, 26 Feb 2019 06:54:12 -0500 Received: from aliyun-cloud.icoremail.net ([47.90.88.95]:30591 "HELO aliyun-sdnproxy-1.icoremail.net" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with SMTP id S1726004AbfBZLyM (ORCPT ); Tue, 26 Feb 2019 06:54:12 -0500 X-Greylist: delayed 358 seconds by postgrey-1.27 at vger.kernel.org; Tue, 26 Feb 2019 06:54:10 EST Received: from bogon.wangsu.com (unknown [59.61.78.237]) by app2 (Coremail) with SMTP id 4zNnewCnJAT_JnVc+aQ9AA--.7800S3; Tue, 26 Feb 2019 19:46:17 +0800 (CST) From: Lin Feng To: linux-kernel@vger.kernel.org Cc: akpm@linux-foundation.org, adobriyan@gmail.com, fabf@skynet.be, arjan@infradead.org, linf@wangsu.com Subject: [PATCH 2/2] kernel/latencytop.c: remove unnecessary checks for latencytop_enabled Date: Tue, 26 Feb 2019 19:46:02 +0800 Message-Id: <20190226114602.16902-2-linf@wangsu.com> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20190226114602.16902-1-linf@wangsu.com> References: <20190226114602.16902-1-linf@wangsu.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-CM-TRANSID: 4zNnewCnJAT_JnVc+aQ9AA--.7800S3 X-Coremail-Antispam: 1UD129KBjvJXoW7Kw4xuFWkKF4kWry7AFykuFg_yoW8CryUpF s7urnFy3y8Ja1j9w1Iga1rCryUJw4rAry7KFyDA3W8Zr1qgr13XrnavF4j9r4jkry7Aan3 XrWqqanrtF4UGaDanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnUUvcSsGvfC2KfnxnUUI43ZEXa7xR_UUUUUUUUU== X-CM-SenderInfo: holqwq5zdqw23xof0z/ Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 1. In latencytop source codes, we only have such calling chain: account_scheduler_latency(struct task_struct *task, int usecs, int inter) { if (unlikely(latencytop_enabled)) /* the outtermost check */ __account_scheduler_latency(task, usecs, inter); } __account_scheduler_latency account_global_scheduler_latency if (!latencytop_enabled) So, the inner check for latencytop_enabled is not necessary at all. 2. In clear_all_latency_tracing and now is called clear_tsk_latency_tracing the check for latencytop_enabled is redundant and buggy to some extent. We have no reason to refuse clearing the /proc/$pid/latency if latencytop_enabled is set to 0, considering that if we use latencytop manually by echo 0 > /proc/sys/kernel/latencytop, then we want to clear /proc/$pid/latency and failed. Aslo we don't have such check in brother function clear_global_latency_tracing. Notes: These changes only visible to users who sets CONFIG_LATENCYTOP and won't change user tool latencytop's behaviors. Signed-off-by: Lin Feng --- kernel/latencytop.c | 6 ------ 1 file changed, 6 deletions(-) diff --git a/kernel/latencytop.c b/kernel/latencytop.c index 9e794b49791e..897895efafd9 100644 --- a/kernel/latencytop.c +++ b/kernel/latencytop.c @@ -71,9 +71,6 @@ void clear_tsk_latency_tracing(struct task_struct *p) { unsigned long flags; - if (!latencytop_enabled) - return; - raw_spin_lock_irqsave(&latency_lock, flags); memset(&p->latency_record, 0, sizeof(p->latency_record)); p->latency_record_count = 0; @@ -96,9 +93,6 @@ account_global_scheduler_latency(struct task_struct *tsk, int firstnonnull = MAXLR + 1; int i; - if (!latencytop_enabled) - return; - /* skip kernel threads for now */ if (!tsk->mm) return; -- 2.20.1