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 EB8C4ECAAA1 for ; Tue, 6 Sep 2022 18:21:55 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 772456B0072; Tue, 6 Sep 2022 14:21:55 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 720358D0002; Tue, 6 Sep 2022 14:21:55 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5E8C78D0001; Tue, 6 Sep 2022 14:21:55 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 4FAA16B0072 for ; Tue, 6 Sep 2022 14:21:55 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 2581D1401C7 for ; Tue, 6 Sep 2022 18:21:55 +0000 (UTC) X-FDA: 79882479390.27.2AF56E2 Received: from out1.migadu.com (out1.migadu.com [91.121.223.63]) by imf15.hostedemail.com (Postfix) with ESMTP id CAD30A006C for ; Tue, 6 Sep 2022 18:21:52 +0000 (UTC) Date: Tue, 6 Sep 2022 14:20:58 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1662488510; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=/bRlcVcrWdQKJLJipKk17c91ZfuMwNoEsJqygzANM10=; b=e2VD/HcikFLJhe0V11ErS/Oin4ybn/TXkbGiMkiUOxLxKEWpdcoX4otQ2quaeh2xN9tkEz gJSSZJlOcx5MH/FwRLBQM+nMzvd03D3L1jInmtTiFs1YUwF1FG/7tFAS2gRVdaASeb5tb9 7SVVXyTQbLTanYnVJHubYmXd6a/lpqA= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Kent Overstreet To: Michal Hocko Cc: Suren Baghdasaryan , Mel Gorman , Peter Zijlstra , Andrew Morton , Vlastimil Babka , Johannes Weiner , Roman Gushchin , Davidlohr Bueso , Matthew Wilcox , "Liam R. Howlett" , David Vernet , Juri Lelli , Laurent Dufour , Peter Xu , David Hildenbrand , Jens Axboe , mcgrof@kernel.org, masahiroy@kernel.org, nathan@kernel.org, changbin.du@intel.com, ytcoode@gmail.com, Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Benjamin Segall , Daniel Bristot de Oliveira , Valentin Schneider , Christopher Lameter , Pekka Enberg , Joonsoo Kim , 42.hyeyoo@gmail.com, Alexander Potapenko , Marco Elver , Dmitry Vyukov , Shakeel Butt , Muchun Song , arnd@arndb.de, jbaron@akamai.com, David Rientjes , Minchan Kim , Kalesh Singh , kernel-team , linux-mm , iommu@lists.linux.dev, kasan-dev@googlegroups.com, io-uring@vger.kernel.org, linux-arch@vger.kernel.org, xen-devel@lists.xenproject.org, linux-bcache@vger.kernel.org, linux-modules@vger.kernel.org, LKML Subject: Re: [RFC PATCH 00/30] Code tagging framework and applications Message-ID: <20220906182058.iijmpzu4rtxowy37@kmo-framework> References: <20220831190154.qdlsxfamans3ya5j@moria.home.lan> <20220901201502.sn6223bayzwferxv@moria.home.lan> <20220905234649.525vorzx27ybypsn@kmo-framework> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Migadu-Flow: FLOW_OUT X-Migadu-Auth-User: linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1662488513; a=rsa-sha256; cv=none; b=c+z8Q22DGCojmZD9/MlRKyUKg4wsW3L2jasVrsnHN/dd/2nMlpmwnpGzvg+vJ+7IcJYTLk z1dDBmiufXP4a2dG308TQ5TDE/cnDxwmm82PhhyEeS6iNxUQe+PDTfkHXY5trBwVFQex3s rQ4WMUJiHw4NsMYylrW2WmLqFvkHhJU= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b="e2VD/Hci"; spf=pass (imf15.hostedemail.com: domain of kent.overstreet@linux.dev designates 91.121.223.63 as permitted sender) smtp.mailfrom=kent.overstreet@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1662488513; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=/bRlcVcrWdQKJLJipKk17c91ZfuMwNoEsJqygzANM10=; b=qc1iPQ48u25IdhoRvDUFZV73ZaNBgzCLgFaxZTK1Byax2akccZIMD3NcKPpHXD505ZpnIY zlJwZWTQsPNK0NXwFwfSn6QfBSmISFFtw9zi0hCTsIA0M8TrUTlRbPfI48xNQRJa55KZ0m twykLBU8jL6WUcGhj0MdNMTvdnMp/Ww= X-Stat-Signature: opese579ysxdt1hgjffb73tcas91etij X-Rspamd-Queue-Id: CAD30A006C X-Rspamd-Server: rspam07 X-Rspam-User: Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b="e2VD/Hci"; spf=pass (imf15.hostedemail.com: domain of kent.overstreet@linux.dev designates 91.121.223.63 as permitted sender) smtp.mailfrom=kent.overstreet@linux.dev; dmarc=pass (policy=none) header.from=linux.dev X-HE-Tag: 1662488512-220543 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 Tue, Sep 06, 2022 at 09:23:31AM +0200, Michal Hocko wrote: > On Mon 05-09-22 19:46:49, Kent Overstreet wrote: > > On Mon, Sep 05, 2022 at 10:49:38AM +0200, Michal Hocko wrote: > > > This is really my main concern about this whole work. Not only it adds a > > > considerable maintenance burden to the core MM because > > > > [citation needed] > > I thought this was clear from the email content (the part you haven't > quoted here). But let me be explicit one more time for you. > > I hope we can agree that in order for this kind of tracking to be useful > you need to cover _callers_ of the allocator or in the ideal world > the users/owner of the tracked memory (the later is sometimes much > harder/impossible to track when the memory is handed over from one peer > to another). > > It is not particularly useful IMO to see that a large portion of the > memory has been allocated by say vmalloc or kvmalloc, right? How > much does it really tell you that a lot of memory has been allocated > by kvmalloc or vmalloc? Yet, neither of the two is handled by the > proposed tracking and it would require additional code to be added and > _maintained_ to cover them. But that would be still far from complete, > we have bulk allocator, mempools etc. Of course - and even a light skimming of the patch set would see it does indeed address this. We still have to do vmalloc and percpu memory allocations, but slab is certainly handled and that's the big one. > As pointed above this just scales poorly and adds to the API space. Not > to mention that direct use of alloc_tag_add can just confuse layers > below which rely on the same thing. It might help you make your case if you'd say something about what you'd like better. Otherwise, saying "code has to be maintained" is a little bit like saying water is wet, and we're all engineers here, I think we know that :)