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 C727BC433EF for ; Mon, 9 May 2022 22:29:03 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3FFEE6B0071; Mon, 9 May 2022 18:29:03 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3AE306B0072; Mon, 9 May 2022 18:29:03 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 276626B0073; Mon, 9 May 2022 18:29:03 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 186DA6B0071 for ; Mon, 9 May 2022 18:29:03 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay11.hostedemail.com (Postfix) with ESMTP id E2F8580DE6 for ; Mon, 9 May 2022 22:29:02 +0000 (UTC) X-FDA: 79447646124.22.0E9A8BF Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by imf01.hostedemail.com (Postfix) with ESMTP id 57A5940038 for ; Mon, 9 May 2022 22:28:51 +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 249MSHo6011967 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 9 May 2022 18:28:18 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=outgoing; t=1652135313; bh=PomMNNmWyc5YBypwEkVpIDxcMt6S+On8bnwlKnLl0F0=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=Rs39OkFP/pNTkSQxZVxoNUvjfqeJsxGjlEaKtnLe8EYOjlpbdGk2tHWkiS9d9BcFF RIS/AIDq54gd3qcAa4HbE2GaHSv1KAhIEOOsohL8REgCHrQHDaElN2R3RR5DILb92k krMVvIOOSSVttntoFPdV+0VPdEuK4jdzgzxcp31ezytw6TdqVQENGAP6bOz/BbSmd9 +UAjd3OyeAuuz3Oxm3sSUqTbAfnKQofWUeaXq8o4sQop7aqBnBEH1MzLZrD38+kmOc JbnmmK0DrKFNfZWR24Bn4TkvdA/n26ClG04VexyZ41JIVMdMdWBkKBvA+xtD1mMnID Vo6X0EhaRd7zA== Received: by cwcc.thunk.org (Postfix, from userid 15806) id A4D2D15C3F0A; Mon, 9 May 2022 18:28:17 -0400 (EDT) Date: Mon, 9 May 2022 18:28:17 -0400 From: "Theodore Ts'o" To: Byungchul Park Cc: 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, tj@kernel.org, willy@infradead.org, david@fromorbit.com, amir73il@gmail.com, bfields@fieldses.org, 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, airlied@linux.ie, rodrigosiqueiramelo@gmail.com, melissa.srw@gmail.com, hamohammed.sa@gmail.com, 42.hyeyoo@gmail.com Subject: Re: [PATCH RFC v6 00/21] DEPT(Dependency Tracker) Message-ID: References: <1651652269-15342-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: Authentication-Results: imf01.hostedemail.com; dkim=fail ("headers rsa verify failed") header.d=mit.edu header.s=outgoing header.b=Rs39OkFP; dmarc=fail reason="No valid SPF" header.from=mit.edu (policy=none); spf=none (imf01.hostedemail.com: domain of tytso@mit.edu has no SPF policy when checking 18.9.28.11) smtp.mailfrom=tytso@mit.edu X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 57A5940038 X-Rspam-User: X-Stat-Signature: n4yiuxrep94gwpf8gr3qwjmdgdba61qx X-HE-Tag: 1652135331-628310 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000264, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Oh, one other problem with DEPT --- it's SLOW --- the overhead is enormous. Using kvm-xfstests[1] running "kvm-xfstests smoke", here are some sample times: LOCKDEP DEPT Time to first test 49 seconds 602 seconds ext4/001 2 s 22 s ext4/003 2 s 8 s ext4/005 0 s 7 s ext4/020 1 s 8 s ext4/021 11 s 17 s ext4/023 0 s 83 s generic/001 4 s 76 s generic/002 0 s 11 s generic/003 10 s 19 s There are some large variations; in some cases, some xfstests take 10x as much time or more to run. In fact, when I first started the kvm-xfstests run with DEPT, I thought something had hung and that tests would never start. (In fact, with gce-xfstests the default watchdog "something has gone terribly wrong with the kexec" had fired, and I didn't get any test results using gce-xfstests at all. If DEPT goes in without any optimizations, I'm going to have to adjust the watchdogs timers for gce-xfstests.) The bottom line is that at the moment, between the false positives, and the significant overhead imposed by DEPT, I would suggest that if DEPT ever does go in, that it should be possible to disable DEPT and only use the existing CONFIG_PROVE_LOCKING version of LOCKDEP, just because DEPT is S - L - O - W. [1] https://github.com/tytso/xfstests-bld/blob/master/Documentation/kvm-quickstart.md - Ted P.S. Darrick and I both have disabled using LOCKDEP by default because it slows down ext4 -g auto testing by a factor 2, and xfs -g auto testing by a factor of 3. So the fact that DEPT is a factor of 2x to 10x or more slower than LOCKDEP when running various xfstests tests should be a real concern.