From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-16.9 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 022B8C433F5 for ; Thu, 16 Sep 2021 01:02:37 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 5C24661186 for ; Thu, 16 Sep 2021 01:02:37 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 5C24661186 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=huawei.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id E3780900002; Wed, 15 Sep 2021 21:02:35 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DE6516B0072; Wed, 15 Sep 2021 21:02:35 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D22FA900002; Wed, 15 Sep 2021 21:02:35 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0235.hostedemail.com [216.40.44.235]) by kanga.kvack.org (Postfix) with ESMTP id C67C56B0071 for ; Wed, 15 Sep 2021 21:02:35 -0400 (EDT) Received: from smtpin05.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 776BA2BFCA for ; Thu, 16 Sep 2021 01:02:35 +0000 (UTC) X-FDA: 78591636270.05.7918B0F Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by imf28.hostedemail.com (Postfix) with ESMTP id 8882790000A3 for ; Thu, 16 Sep 2021 01:02:34 +0000 (UTC) Received: from dggemv703-chm.china.huawei.com (unknown [172.30.72.54]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4H8zGM50MFz8yZ6; Thu, 16 Sep 2021 08:58:03 +0800 (CST) Received: from dggpemm500001.china.huawei.com (7.185.36.107) by dggemv703-chm.china.huawei.com (10.3.19.46) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.8; Thu, 16 Sep 2021 09:02:29 +0800 Received: from [10.174.177.243] (10.174.177.243) by dggpemm500001.china.huawei.com (7.185.36.107) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.8; Thu, 16 Sep 2021 09:02:28 +0800 Subject: Re: [PATCH v2 2/3] kfence: maximize allocation wait timeout duration To: Marco Elver , CC: , , , , , , , References: <20210421105132.3965998-1-elver@google.com> <20210421105132.3965998-3-elver@google.com> From: Kefeng Wang Message-ID: <6c0d5f40-5067-3a59-65fa-6977b6f70219@huawei.com> Date: Thu, 16 Sep 2021 09:02:27 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <20210421105132.3965998-3-elver@google.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Originating-IP: [10.174.177.243] X-ClientProxiedBy: dggems704-chm.china.huawei.com (10.3.19.181) To dggpemm500001.china.huawei.com (7.185.36.107) X-CFilter-Loop: Reflected Authentication-Results: imf28.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=huawei.com; spf=pass (imf28.hostedemail.com: domain of wangkefeng.wang@huawei.com designates 45.249.212.188 as permitted sender) smtp.mailfrom=wangkefeng.wang@huawei.com X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 8882790000A3 X-Stat-Signature: bjbsbep9338o8w56fegxfiu1scs9yqwj X-HE-Tag: 1631754154-240240 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 2021/4/21 18:51, Marco Elver wrote: > The allocation wait timeout was initially added because of warnings due > to CONFIG_DETECT_HUNG_TASK=y [1]. While the 1 sec timeout is sufficient > to resolve the warnings (given the hung task timeout must be 1 sec or > larger) it may cause unnecessary wake-ups if the system is idle. > [1] https://lkml.kernel.org/r/CADYN=9J0DQhizAGB0-jz4HOBBh+05kMBXb4c0cXMS7Qi5NAJiw@mail.gmail.com > > Fix it by computing the timeout duration in terms of the current > sysctl_hung_task_timeout_secs value. > > Signed-off-by: Marco Elver > --- > mm/kfence/core.c | 12 +++++++++++- > 1 file changed, 11 insertions(+), 1 deletion(-) > > diff --git a/mm/kfence/core.c b/mm/kfence/core.c > index 235d726f88bc..9742649f3f88 100644 > --- a/mm/kfence/core.c > +++ b/mm/kfence/core.c > @@ -20,6 +20,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -621,7 +622,16 @@ static void toggle_allocation_gate(struct work_struct *work) > /* Enable static key, and await allocation to happen. */ > static_branch_enable(&kfence_allocation_key); > > - wait_event_timeout(allocation_wait, atomic_read(&kfence_allocation_gate), HZ); > + if (sysctl_hung_task_timeout_secs) { > + /* > + * During low activity with no allocations we might wait a > + * while; let's avoid the hung task warning. > + */ > + wait_event_timeout(allocation_wait, atomic_read(&kfence_allocation_gate), > + sysctl_hung_task_timeout_secs * HZ / 2); > + } else { > + wait_event(allocation_wait, atomic_read(&kfence_allocation_gate)); > + } > > /* Disable static key and reset timer. */ > static_branch_disable(&kfence_allocation_key);