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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6467DC433EF for ; Thu, 12 May 2022 13:57:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DD1F56B0074; Thu, 12 May 2022 09:57:29 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D577A6B007B; Thu, 12 May 2022 09:57:29 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C1FBB6B007D; Thu, 12 May 2022 09:57:29 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id B2FA06B0074 for ; Thu, 12 May 2022 09:57:29 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 89BC520CDE for ; Thu, 12 May 2022 13:57:29 +0000 (UTC) X-FDA: 79457243418.21.759F679 Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by imf13.hostedemail.com (Postfix) with ESMTP id 9FD8A200A6 for ; Thu, 12 May 2022 13:57:10 +0000 (UTC) Received: from cwcc.thunk.org (pool-108-7-220-252.bstnma.fios.verizon.net [108.7.220.252]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 24CDukvd025718 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 12 May 2022 09:56:47 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=outgoing; t=1652363814; bh=fK1JutfKwB9RZi7LGZBoNzqwgl48auY9kCDUP4LKjGo=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=nzpfnyp3va4UeNMJsIUwRARvxBhDqDdf3HsaJ8eucf+Epey6lQyyZbRyGPs4LKIYI zXUD/hTUINDuYbnfWjRFJsujUU3jqAP9AldIHfRTfcN1fe1JS0ZEotNuRb1F1qTxAZ R9fIMtFXp7hWAd0/axDvHxk1rsvu0eWxchvLrSXgv/0vesv652yMZ2M4g3OKHiwgJ6 fZLCYRBs9DGpyW5b1gmYVYp+J4TUBNPPrdB5DZXLCY0rBxk9sty2gP9f56TUH80yQg eTIbHMo+uceLQlZEif4OE9g5l7MQGzmHNj3egipGOK3AAGcfJQ2L2E7+1UwHHBtnU4 MZd6AUIq1ki4Q== Received: by cwcc.thunk.org (Postfix, from userid 15806) id B5CC215C3F2A; Thu, 12 May 2022 09:56:46 -0400 (EDT) Date: Thu, 12 May 2022 09:56:46 -0400 From: "Theodore Ts'o" To: Byungchul Park Cc: tj@kernel.org, torvalds@linux-foundation.org, damien.lemoal@opensource.wdc.com, linux-ide@vger.kernel.org, adilger.kernel@dilger.ca, linux-ext4@vger.kernel.org, mingo@redhat.com, linux-kernel@vger.kernel.org, peterz@infradead.org, will@kernel.org, tglx@linutronix.de, rostedt@goodmis.org, joel@joelfernandes.org, sashal@kernel.org, daniel.vetter@ffwll.ch, chris@chris-wilson.co.uk, duyuyang@gmail.com, johannes.berg@intel.com, willy@infradead.org, david@fromorbit.com, amir73il@gmail.com, gregkh@linuxfoundation.org, kernel-team@lge.com, linux-mm@kvack.org, akpm@linux-foundation.org, mhocko@kernel.org, minchan@kernel.org, hannes@cmpxchg.org, vdavydov.dev@gmail.com, sj@kernel.org, jglisse@redhat.com, dennis@kernel.org, cl@linux.com, penberg@kernel.org, rientjes@google.com, vbabka@suse.cz, ngupta@vflare.org, linux-block@vger.kernel.org, paolo.valente@linaro.org, josef@toxicpanda.com, linux-fsdevel@vger.kernel.org, viro@zeniv.linux.org.uk, jack@suse.cz, jack@suse.com, jlayton@kernel.org, dan.j.williams@intel.com, hch@infradead.org, djwong@kernel.org, dri-devel@lists.freedesktop.org, rodrigosiqueiramelo@gmail.com, melissa.srw@gmail.com, hamohammed.sa@gmail.com, 42.hyeyoo@gmail.com, mcgrof@kernel.org, holt@sgi.com Subject: Re: [REPORT] syscall reboot + umh + firmware fallback Message-ID: References: <1652354304-17492-1-git-send-email-byungchul.park@lge.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1652354304-17492-1-git-send-email-byungchul.park@lge.com> X-Stat-Signature: 19mjqfr78aw6cskyye41khxaa6ame4wb X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 9FD8A200A6 X-Rspam-User: Authentication-Results: imf13.hostedemail.com; dkim=fail ("headers rsa verify failed") header.d=mit.edu header.s=outgoing header.b=nzpfnyp3; dmarc=fail reason="No valid SPF" header.from=mit.edu (policy=none); spf=none (imf13.hostedemail.com: domain of tytso@mit.edu has no SPF policy when checking 18.9.28.11) smtp.mailfrom=tytso@mit.edu X-HE-Tag: 1652363830-582056 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000039, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Thu, May 12, 2022 at 08:18:24PM +0900, Byungchul Park wrote: > I have a question about this one. Yes, it would never been stuck thanks > to timeout. However, IIUC, timeouts are not supposed to expire in normal > cases. So I thought a timeout expiration means not a normal case so need > to inform it in terms of dependency so as to prevent further expiraton. > That's why I have been trying to track even timeout'ed APIs. As I beleive I've already pointed out to you previously in ext4 and ocfs2, the jbd2 timeout every five seconds happens **all** the time while the file system is mounted. Commits more frequently than five seconds is the exception case, at least for desktops/laptop workloads. We *don't* get to the timeout only when a userspace process calls fsync(2), or if the journal was incorrectly sized by the system administrator so that it's too small, and the workload has so many file system mutations that we have to prematurely close the transaction ahead of the 5 second timeout. > Do you think DEPT shouldn't track timeout APIs? If I was wrong, I > shouldn't track the timeout APIs any more. DEPT tracking timeouts will cause false positives in at least some cases. At the very least, there needs to be an easy way to suppress these false positives on a per wait/mutex/spinlock basis. - Ted