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 65C3BD15DB8 for ; Mon, 21 Oct 2024 16:15:59 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D724B6B0082; Mon, 21 Oct 2024 12:15:58 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D22C86B0083; Mon, 21 Oct 2024 12:15:58 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BEA5A6B0085; Mon, 21 Oct 2024 12:15:58 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 9DD066B0082 for ; Mon, 21 Oct 2024 12:15:58 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id C28DAAC711 for ; Mon, 21 Oct 2024 16:15:27 +0000 (UTC) X-FDA: 82698109830.20.9C278FD Received: from mail-lj1-f182.google.com (mail-lj1-f182.google.com [209.85.208.182]) by imf13.hostedemail.com (Postfix) with ESMTP id DD1CC20019 for ; Mon, 21 Oct 2024 16:15:40 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="Aw5SYM/F"; spf=pass (imf13.hostedemail.com: domain of urezki@gmail.com designates 209.85.208.182 as permitted sender) smtp.mailfrom=urezki@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1729527157; 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=hDCkRXzZMsmC9OcdH/PJ2FucYewOH9vBwnV76xL3TNM=; b=OReOer9uP0uhpsfJSHTqSnMhG/Z/F4CtV2OPm6HDqp0UFdoRphvmCVtD2hRI/GfkfBnWgg MYnYB+QVDdBbM0PC6kIZ1Rc2iPI7Sc/e/jLlyqbGMJvOUqvBextb5jg9o7jQNuCpTv/lru AofmhpdzPvztf0jCPB4+mQgUnTuClnI= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="Aw5SYM/F"; spf=pass (imf13.hostedemail.com: domain of urezki@gmail.com designates 209.85.208.182 as permitted sender) smtp.mailfrom=urezki@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1729527157; a=rsa-sha256; cv=none; b=HlpIa4vIqFZ+D1YYMCu895p4xwh/gNw7sfiSeKaEIbz5jdRpur8eeJmQDxY/7btfU1W9IP krMw3P1IJB3MCV9Dm6e32D1a1x1OGSKo4lvyqwWIPu0oOHhVg3UfE2vhhZMwdg2grmjkzR UujZr4aPlG3rNDZJDCPPdVrPdd/10m4= Received: by mail-lj1-f182.google.com with SMTP id 38308e7fff4ca-2fb501492ccso46683141fa.2 for ; Mon, 21 Oct 2024 09:15:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1729527354; x=1730132154; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:date:from:from:to:cc:subject:date:message-id:reply-to; bh=hDCkRXzZMsmC9OcdH/PJ2FucYewOH9vBwnV76xL3TNM=; b=Aw5SYM/F+zuK5Mwsx+G19H04nY5Bq3MDCuu2AQCSSZ9VqP90s3jIhKRB84+A2eZ6rc IIMB9fHGXR6e9aS51EDbPSEBfUSo/oYX/T6Ows8en0umti5FtVrJoTxSjv3szHBz0PTQ AjDUpwDxxA0TOQhJEX9S1DmxWBxjMVwCzgP3UgHS8+8WA+SHu5Xuu/dgCG6BZulgs8TU SnPuttUPIpx2W3sNDeVCUIkas8aDeMaRmNEupGAkKwJ+vPni4TnBh1RCid9BaQTpTTEZ BEe5HC3lA89Z29rVODPfPq5X5LjlSwkSgV3yl8vdKQ6uuuLEKNMknS12HvG1uKo4KUcp GA6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729527354; x=1730132154; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:date:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=hDCkRXzZMsmC9OcdH/PJ2FucYewOH9vBwnV76xL3TNM=; b=QXsbTOEYippaD+LYjge1wOdjQwFHWqhXnf06xszxaBrYV5u3FijiprfYMWBM4o3FXJ sob3QiIGCvcCtEfe3LUnQmP7YBmSoHnpdFptbaAe+kkNWxH/b6OcJhjUp0E0Yz7/3jUC DhuNHcqWzU1iJJci46SbCr7KdEnO4exIxasWWd36FNvCbJ0QnOYup+AU5xKU23qzBC9F fjEPjh+0q29c2uFL+oZpsHEoINmRigtJ00fHZjhiZhHwGSiQHR5bzyL8QbcisTR1oCBm XxaAG4nrSVmUzyrkyMX+DsJDhz/B1aJ1+hNx01gC5yKI5mcW6gLYxwUGufoyCocRCaYI vsrQ== X-Forwarded-Encrypted: i=1; AJvYcCUiJWDSb8w3I/iNz8k5otIqfpfLS/XzRT1lA6ziYOixfNSoKz1P9Q4tf756WbpAlTPu6wG/aGO+aQ==@kvack.org X-Gm-Message-State: AOJu0YwgcBurhixn3i1mXIp1Fax9PnkQUHxhHPG47Kc9d6BhEY6U2ofL pXgZxD1HmghuuJKzFYbFWPJx4DotO9XZMnnjHecowITZXWHx1fwZ X-Google-Smtp-Source: AGHT+IG2h1dAnakaDzA9jqhK0kzf0ExHRZDYTYVZSzXXU1tOMfyuMkFIlh/zpiO3wAsQhBR/2UjqXw== X-Received: by 2002:a2e:d01:0:b0:2fb:b59:8167 with SMTP id 38308e7fff4ca-2fb8320ba5emr44846581fa.39.1729527354158; Mon, 21 Oct 2024 09:15:54 -0700 (PDT) Received: from pc636 (host-90-233-222-236.mobileonline.telia.com. [90.233.222.236]) by smtp.gmail.com with ESMTPSA id 38308e7fff4ca-2fb9ad4b843sm5296961fa.4.2024.10.21.09.15.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 21 Oct 2024 09:15:53 -0700 (PDT) From: Uladzislau Rezki X-Google-Original-From: Uladzislau Rezki Date: Mon, 21 Oct 2024 18:15:50 +0200 To: Kent Overstreet Cc: Linus Torvalds , 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: <20241019210037.146825-1-kent.overstreet@linux.dev> <90bc0794-4cab-415f-a442-4af85a32eed8@lucifer.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: DD1CC20019 X-Stat-Signature: qiuokafa59an873f9pabkj5kfjf9wt71 X-Rspam-User: X-HE-Tag: 1729527340-750793 X-HE-Meta: U2FsdGVkX1/5zpCx+xFICkyBBtMcBX87+b6HXHNApSqYyXXCaiWpay6C8JnH0Dl9X1PEMv1a2kka76UomPGy4OC/Io0i91v8vI9MHh7pd1UjpcwEQaEk1OUNIODPgIBXl9q7VeuY92I0XSfOY46IrLUJyWJ0u2Z1kxDcHcw9COSE3hNlwkb9EkFt26UXEKPlzzQ3ik+eDcCJ0M9tT1zS/PBXv+ahuvgyT5E/gRVZbHmOANyAE/Vsau9y725fOZQFcWvQYBwCOVSafvjbmsCliH1JJRXcttCuITYMQEkeHdwO1WhrARxFrUHmSH+a6Cofdt9b4N8lG5220JeblTkcbVHR2/esC0qYUkM+YuyiR05DuXyg7tibromClBEk7tbOb4yUZe8IYaj784me7qXeDpm3WVIDfQ9Kb9a6AAJW4a57w0eCiVeSq+3rFPhGH1X9dnlcJ4hCPOTaiWOWr9efESnmfwWjgwmV+AM0S909tMTEKSUZXLzDV3KzFYE9vBjw3hODoUsbgZts8/5Xdv3sqwVfnunH9geNe4XShF28JQlom7QrIKosHHh6hOOf8sKbpV70WIOROORyQLyAFsjqLOF1o1nyHI9svRnAP09ikKqdrQyiT8MJ5sLhdeePv3i6Y6EBN26oWgVEER9Akm1uvExyoX0ChdDZbkueiY0RYNXvMps/fz8pniJg1CUh2TrbHwmGsOpZEFEKtBO2FTPIStpuibmRGw9DDst4ZDiWjNoOBmSf3xRo8+YDmTGFhhA07d8QHaUfi9hpZfXW/LckplN/hv0DPjgLTS/o6IyJXt2fp1yJ9nMAsofbGTdyb6roEIqT2z/U4Qgp6Xj2s29jgzCgvaaJ8vCpk/0cCDt39Fk+0LXqaSnQdNtMhfvIc2h4ZNgVV92MKq0yIhxFRr/otsDbpIskKAOgobhOWCAmvuhQ3tAIf1xTU0GLn7ZUaamRWsx7G+0/OC7dMbUOpQ4 LMEpk5mt tPetqK+4D9ePziEJFjdlU87r53xW0gCDc5ZoIC3CgrOp9M1RY/88WAHiYm87LoNLUYSPo/Gj8LM8LpYTLvatI2WFOS2cmwIPDnwreke9VdDj4EDSRRstnCbn6wch2zTVXdZIRuoXERuHrsZ7kDPuV1McCOUBEqEfF+ikVU8zPF962V4HikRPYXoeoQSD4WnoPosrfdYxMX5xdgb5Utp26ZjdbalJOiBM5Bz48f6+iad0Ii1VWBSyEnS1jKJlL9ngOK1DTw9pTG1MmOQxchD8JmKUnynYDYyryvQlaRF69y7XMG4+gFIdXwE6IVLXydW0gPjty9nT9A9s1CFOxeGrnUrmxQQy1VigHJ1P9UQ5ikGrloRnSnezFn0cz22u+R9MhK5KbMgJV+6H3jL4I5xUmdXCA/VgzPJjr+mOJbmu9wv47RLoexq01NTYhBrBQ8rhyyXcBCfcX7CM8qDUVU6lfH6ctcewOlDjLUj3F6J8qH8IW5BNwMSrcHoLdZg== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000001, 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 03:16:11PM -0400, Kent Overstreet wrote: > On Sun, Oct 20, 2024 at 12:09:58PM -0700, Linus Torvalds wrote: > > On Sun, 20 Oct 2024 at 12:09, Linus Torvalds > > wrote: > > > > > > How about you limit the amount of memory you use in the first place instead? > > > > .. and to clarify: we're not making other parts of the kernel less > > robust because *you* are doing something stupid and odd. > > Except, vmalloc() already behaves this way - so it seems to me you > already have. > > I've already added a stupid workaround to the darray code to switch to > calling vmalloc() directly, when necessary; this patch was a courtesy > because if bcachefs is hitting this limit no doubt other things will be > soon as well. > I was thinking to prevent "big" allocations to limit the vmalloc() by the INT_MAX sizes, i.e. to apply same limitation as kvmalloc() has. vmalloc() is stick to totalram_pages() which is way a lot. But it would break bcachefs, as i see it. -- Uladzislau Rezki