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=-13.3 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=no 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 87782C433F5 for ; Thu, 16 Sep 2021 15:48:28 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 1168B6120E for ; Thu, 16 Sep 2021 15:48:28 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 1168B6120E Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id A02F9940008; Thu, 16 Sep 2021 11:48:27 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9B303940007; Thu, 16 Sep 2021 11:48:27 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8536F940008; Thu, 16 Sep 2021 11:48:27 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0222.hostedemail.com [216.40.44.222]) by kanga.kvack.org (Postfix) with ESMTP id 76655940007 for ; Thu, 16 Sep 2021 11:48:27 -0400 (EDT) Received: from smtpin03.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 2416F2775D for ; Thu, 16 Sep 2021 15:48:27 +0000 (UTC) X-FDA: 78593868654.03.6B2732B Received: from mail-oo1-f50.google.com (mail-oo1-f50.google.com [209.85.161.50]) by imf10.hostedemail.com (Postfix) with ESMTP id D4CED6001995 for ; Thu, 16 Sep 2021 15:48:26 +0000 (UTC) Received: by mail-oo1-f50.google.com with SMTP id l17-20020a4ae391000000b00294ad0b1f52so2194311oov.10 for ; Thu, 16 Sep 2021 08:48:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rD3TrezbVLYHxHI60H3QOHHxKkUHFG/XFIP2soX5eXI=; b=r9/FKsGRZxXmFM5lvEMuZE+ffceWdPYMAOrxxA24P8B0Au4MU/ZZz3vUUCjFdXCi3k 42AQKWu7i3+zTGocdosajg4EwaklRHUAtK52+q6qA6w+YYC/9CYkAXMU/WO33AtKbpn4 kqRqHSKRvdswhjlGOanL5WS/j+cDY5FBbVqYeS3PIoPYmLA9B/6+dnoJjYnOGPS0JNW6 w6tOFJuju01axPG6Xbk079jVi15R9ckiG4+WDBelTKCKm2j+esuqtMEJRdhzseZsuwOv x+dLefRbddFbaUuTZVxdFccm7D6MCagaygz6jFHAMpUCYnqWjZ7FJXXaJ8jbnlhia0l9 M0aA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rD3TrezbVLYHxHI60H3QOHHxKkUHFG/XFIP2soX5eXI=; b=dY0pBTv/tssuhSqysbmeWSU8recPEqRc0NPZRrfQJYIidpQ5XLhp8VQL4MsWP+Wj0c PvI31E7/YyDfoq9HAhQLvSbwcdw0C7a2335womRevvM+mSpC2IzcYx5phRDl1hpRIvWT R/+TOEw9nHTQGDs44EtStbjCsKTsoyiJtFwqIpia86L86naI6GwpLDxL8XgnyfBg8OcY nsIjplRWTWbjw1lRkg7gt57FHupq/P8xWBcjgg5el4CJnaqEtR+v9UiDSJpD9/vKZnvX SCssAwWGD48ZBAYtesnsmGfpp19ipEWaKzy2mXavF6Xn3jFq1bVTOl8b8GVhh5uZe74E WkDw== X-Gm-Message-State: AOAM533c750oFwHu+sSAzz152dJirkIPCJBiTPN8EEuuRnrk0H1Zb56p qJKFJ689758t34lXVL8tA1oJKHSV4/Hwn+5olZuEuA== X-Google-Smtp-Source: ABdhPJyglXbT5duFWaAC2wJjOoTihuxBgokAfIkKTcyjjBv8P1RhULB7cFk7Y1AL7PUYSwq3MNi8/7nuKyLiaMWaWLI= X-Received: by 2002:a4a:4344:: with SMTP id l4mr4919522ooj.38.1631807305859; Thu, 16 Sep 2021 08:48:25 -0700 (PDT) MIME-Version: 1.0 References: <20210421105132.3965998-1-elver@google.com> <20210421105132.3965998-3-elver@google.com> <6c0d5f40-5067-3a59-65fa-6977b6f70219@huawei.com> <858909f98f33478891056a840ad68b9f@AcuMS.aculab.com> In-Reply-To: <858909f98f33478891056a840ad68b9f@AcuMS.aculab.com> From: Marco Elver Date: Thu, 16 Sep 2021 17:48:14 +0200 Message-ID: Subject: Re: [PATCH v2 2/3] kfence: maximize allocation wait timeout duration To: David Laight Cc: Kefeng Wang , "akpm@linux-foundation.org" , "glider@google.com" , "dvyukov@google.com" , "jannh@google.com" , "mark.rutland@arm.com" , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , "kasan-dev@googlegroups.com" , "hdanton@sina.com" Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: D4CED6001995 X-Stat-Signature: kz985dt74fztabcn1h65j85yaxer4f3k Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b="r9/FKsGR"; spf=pass (imf10.hostedemail.com: domain of elver@google.com designates 209.85.161.50 as permitted sender) smtp.mailfrom=elver@google.com; dmarc=pass (policy=reject) header.from=google.com X-HE-Tag: 1631807306-404693 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000033, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Thu, 16 Sept 2021 at 17:45, David Laight wrote: > > From: Kefeng Wang > > Sent: 16 September 2021 02:21 > > > > We found kfence_test will fails on ARM64 with this patch with/without > > CONFIG_DETECT_HUNG_TASK, > > > > Any thought ? > > > ... > > >> /* 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); > > It has replaced a wait_event_timeout() with a wait_event(). > > That probably isn't intended. > Although I'd expect their to be some test for the wait being > signalled or timing out. It is intended -- there's a wake_up() for this. See the whole patch series for explanation. The whole reason we had the timeout was to avoid the hung task warnings, but we can do better if there is no hung task warning enabled.