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 4EDA3D3C92D for ; Sun, 20 Oct 2024 20:30:02 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AC2996B007B; Sun, 20 Oct 2024 16:30:01 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A712C6B0082; Sun, 20 Oct 2024 16:30:01 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 960386B0083; Sun, 20 Oct 2024 16:30:01 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 7949C6B007B for ; Sun, 20 Oct 2024 16:30:01 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 7630B1C6986 for ; Sun, 20 Oct 2024 20:29:44 +0000 (UTC) X-FDA: 82695122034.28.C017422 Received: from out-174.mta0.migadu.com (out-174.mta0.migadu.com [91.218.175.174]) by imf03.hostedemail.com (Postfix) with ESMTP id 7E50D20017 for ; Sun, 20 Oct 2024 20:29:52 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=LJtRMZ1g; spf=pass (imf03.hostedemail.com: domain of kent.overstreet@linux.dev designates 91.218.175.174 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=1729456051; 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=HJCGZp82jco9S+8nHg93J4Lno8LxTucGPuBhIGaxGsE=; b=NbNUMsP6ZzShSI2xEscbEBysQtKX59pyxMAq6SXMfkkWg5KK6Orz2h6zsG2/YnDo7xRDZF 38tLIuNHCDbeOlqGVjsil5NtrfAdSkHNICsQmC5Djy3N4xmY19yRza6oC8n1i9w68+sTD3 i/l8KmkDyLUozaRh7rDnk9b55KG/Xxs= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1729456051; a=rsa-sha256; cv=none; b=Szx7uwlPzXa2GExTGr7mIY/RJVbYSkKFBdNvrXDtWjNQOezu0qCm/t6kvSrD5Nn9sMLPbT iFOXlcDOMHZ82eVLiLckG2+h8l5yj1AZUmyyGPA/CRYKXwA8a93aiGQMlQKz084o1QwaaB BqxMfgWoHX7MKdaKLiPxmGmaOwsPOco= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=LJtRMZ1g; spf=pass (imf03.hostedemail.com: domain of kent.overstreet@linux.dev designates 91.218.175.174 as permitted sender) smtp.mailfrom=kent.overstreet@linux.dev; dmarc=pass (policy=none) header.from=linux.dev Date: Sun, 20 Oct 2024 16:29:52 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1729456196; 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=HJCGZp82jco9S+8nHg93J4Lno8LxTucGPuBhIGaxGsE=; b=LJtRMZ1g6OfCEqbnQSgWNT6D6QoXBZyfjcrXT4RRr6l4LNGMiI/zABSn3ywx59/hv7DP/C ppp3ijm7ENbwtSD2hWEcXNPDwLNN9JZGUatbje2b0yGRBGMWmJsiALwIJdvVOD7uS+ExpC 7LwqGqtNBZnaBGUn/Ja1oYDxb/MXg5c= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Kent Overstreet To: Linus Torvalds Cc: Lorenzo Stoakes , linux-bcachefs@vger.kernel.org, linux-mm@kvack.org, Vlastimil Babka , Andrew Morton , Uladzislau Rezki , Christoph Hellwig Subject: Re: [PATCH] mm: Drop INT_MAX limit from kvmalloc() Message-ID: References: <90bc0794-4cab-415f-a442-4af85a32eed8@lucifer.local> <6eo3gekf6twbnzhpsi2emz2s6sgtof6iba2rvbor7himmejoq5@qbfwtpbpvqoe> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Migadu-Flow: FLOW_OUT X-Rspamd-Queue-Id: 7E50D20017 X-Stat-Signature: frbubxpc8za4y64c75imh91pygbj5trn X-Rspamd-Server: rspam09 X-Rspam-User: X-HE-Tag: 1729456192-341737 X-HE-Meta: U2FsdGVkX1+KtkYnGewviwuc3foJLpnr5f5ixw3tsD/rDFzwI2V8voX37dGkLTUpOnLODClYRZNcNfCuaTk91rffRnxjm+oO4ZZf1qJhoIe72MO8bnZnYUnETMrDzvzB+9xaSC9BrodFLJPUMF+98gPV5ao8T+h38P+2u9Z8eLtebgRRo5N65euXZnebMMQ6WBuTQ/Sccde4sQjMZ1xXkJFVqgnbNKjvcGUvVBhG6KTJQcSY0JYYjmReD/B66S6jEEInTHpLV0WoltuiXS4LTpfeZRjeVaE9QrfkqKrCUhPmpfVHNLR6VR7Qq2KlA/k0eKSmbW1DgNLN8HRsMGTWtWJOCL0SPQksvElkLTJpWpB/w3ezGhctLnA+LIV4YDibuWM3GtxCaDOeVQMZd34USH1qew+KTXr0BRudl/RuzFMAPg/0ftxwhQZCvSL/FbU4BA+q4D5Sy9sldUUusZcTRAOPS57Fg0ktPjd1k9avS/fhmP5VK/cedtNnGmSgslFUCROw6nmtUhZL2P5+NKHeseJH1NvraG1znYxWtak7HEGSUL+1l7tFM9snzJwSMfRxdfDUJByxEzFskhpyQNGMg9t4K1b2y0GOGhqoqKvCcjLJzdJX+6szjjn03xwdxIw34ExXiDCaEy2T4ivnLdpSWWfp0s1RNEgoUTCa0bcQdGRC7t/JBZF3PgkWgUNmAyiaTk2/Aw1j04024K1ApdHM50lNhWcOrxOWI8eAEKqYL6BdK1Rf0bM2RTp2X2CRFLZiOktYHRSfMgnE+RBxL6qH+ePyON6ztHaYH9rWN4x9x4XEEMkh+N9iQX2RRq1yT66dFGlMIvY8RKf0HVvMJVW/hjIV9l9IA3K196qazKgL87hE2NvA6IQspBIovrl8kTfFXr38nSkEO8ZhiRvHbxhjzamoTKhpnkQ3lmMkkVHoiE2Z7Ji7xqQ+uUaZtEonwf8IsbM278uyT2QO1gyGXGa JSkM8cFD nKgD9gBtKJlsRk1jkPGQcG4hDnGX4JdOrq7adZ1sGFNYqINF+pExvTtcyh+/HNwHyCicDlQKchImMmsBLfDR18SlhfN7/aE/GZ0CbUGRUu4FSrKzgM33qHkjPBJ/TY0oDIV63BGLPSTXQ0HSvsuryaKgCMf8ZVFm+MdAGxtO8mnKUSRcYQXAp54Qao/IK1/eVgV5O 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: List-Subscribe: List-Unsubscribe: On Sun, Oct 20, 2024 at 01:19:42PM -0700, Linus Torvalds wrote: > On Sun, 20 Oct 2024 at 13:10, Kent Overstreet wrote: > > > > And the INT_MAX check wouldn't catch truncation anyways - it'd only > > catch integer _underflow_, but allocation size calculations pretty much > > as a rule never use subtractions, so I don't think this check was ever > > worth much to begin with. > > It fixed a real security issue. Which you quite conveniently aren't naming. > Enough said, and you're just making shit up to make excuses. > > Also, you might want to start look at latency numbers in addition to > throughput. If your journal replay needs an *index* that is 2G in > size, you may have other issues. Latency for journal replay? No, journal replay is only something happens at mount after an unclean shutdown. We can afford to take some time there, and journal replay performance hasn't been a concern. > Your journal size is insane, and your "artificial cap on performance" > had better come with numbers. I'm not going to run custom benchmarks just for a silly argument, sorry. But on a fileserver with 128 GB of ram and a 75 TB filesystem (yes, that's likely a dedicated fileserver), we can quite easily justify a btree node cache of perhaps 10GB, and on random update workloads the journal does need to be that big - otherwise our btree node write size goes down and throughput suffers. > Why do you keep on being the person who creates all these pointless > arguments? Not just with me, btw. That's only going to get the biggest eyeroll ever.