From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-lf1-f50.google.com (mail-lf1-f50.google.com [209.85.167.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 45468363C4C for ; Mon, 27 Apr 2026 16:29:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.167.50 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777307362; cv=none; b=SFpUyQgd9XYi9/Bm1aBcyQalI+ttRgT8+Wxmzq7AYRAIsQuM9iogly+XA3iCAy5EZK+jQczQdajNUpmbwWqYcxI5O9VGZfZS+FaAtD3zH7xTF1GqpygUraiJHS3PRLDotdmytO5b2iVaGRIbIXRmxTn6B/b8d11A//tgOtRr6wo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777307362; c=relaxed/simple; bh=6LUtPMnYn9h3dHYUyVjjemTe9eVuYNqQ8Xlb1yCTkVU=; h=From:Date:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=iD1PcQPUsh1dnS/ALSg5pQ9VCeeCNJQSbonSzyxKxs8Z+8LdwAsdNsSdgxcjT512ct/be3kEz6afMvypFj5obmuK6oW4B2ou5x7Biv9r/HfW8mC+kBlieoImEZ/YCNvZa/K/ITi0CTAHVhkP7VWGYOeadOpGN7rKhxs9kmUWy7o= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=SOcbNVhv; arc=none smtp.client-ip=209.85.167.50 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="SOcbNVhv" Received: by mail-lf1-f50.google.com with SMTP id 2adb3069b0e04-5a3fcb2c718so8984859e87.0 for ; Mon, 27 Apr 2026 09:29:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1777307359; x=1777912159; darn=vger.kernel.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=DSfx7+SmbHArcxIwIbdzwX89/TyvDFQ+ngyr7SD3GvA=; b=SOcbNVhvJorpsDSrxL5YatedGNQclmHyn9+ClO6+9evbAQ8xur6fh5iA6jzwA4OIW1 HLHmjFJ4CZ+hK/v52G2//cc9I1+YWe2U2VogUB+xeNviJvLoZbe7uxFpbjg92t3aFlDM Ml/RQeVHFD7Mn8ogx/m708zckgbwrliXIUOx+/6/s9t6SP54bXkcm9Ua0HOkVvRkrT4o ZcB7u1eREGurEiOkRAxRB3Ev9C2OZFa4TGLvsQdwVQHl/8R/509PuGm46gJzeqCuUiGR Q17SLttciVJ58AISlXhaihL9hZDkR5MLmUvrhSq5s+eV1QQquvzva6SyOk5Zn1nTqbIi H5aw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1777307359; x=1777912159; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:date:from:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=DSfx7+SmbHArcxIwIbdzwX89/TyvDFQ+ngyr7SD3GvA=; b=FJCvHZONjKxTiXDtkDNBD/ufaFz80fY0hqOK1XX0HZdJprMTGpQq5I8wGYpvTwAteu n9vVN6xXWk2LvoVuHChyn/347lQzu/aAxf/hun+dM4Q3mlb9JPnYAJt8fCkiLtCDnV7D DaNVjqOkFFyrXYPnFo2/5MRY8dxjC0tPAQsE39Gs10NsjRSkK0Zi8i5NB8iGqvjdOm/P i0ufPFn8cgGlF+xiQrHRWh9s+O0janQcoB6iZDj24kwu26krJiQoRey0Bsq/VOT/DpzY MbhmKBcQGy5Zyn0gtBbH8xlC5zFij8vPW7wU5UwAdvXfRVgxEYxW6M1WBuqJfkCDF7bo 6qew== X-Forwarded-Encrypted: i=1; AFNElJ88uhCD3cdKAYcltNQ35D15nZGh7gZKtDaV3oHYmgUIXGYny/hA+xw5Xm8Ma9M9Mp/6sxPSUkuQDqQPicY=@vger.kernel.org X-Gm-Message-State: AOJu0YwKN5hFFX9zxpkB2/cdOSDZs4sIq5/PUgfwQ0rULw1TogO4LQz6 GovALNz4UdI2XDHApiyyLuxRvx/jdgDkjUxSaFODVx/DhFuSqsWgBgYw X-Gm-Gg: AeBDieuqaUrXcw9A4vWl2KLXji25+NjzAyLffdr47WeB5eQURUK09o7tjwcifBWinrH LexWiQCfAnVJHlqFpud0lTr9Xu9qPSmsHR9jdTT/OMkxce8Yg7eojy145ijBppUGxRBqjGGFbtf 8CVLjBKqhZShiRt723cBYTi860X30ikTOCsmaOw5HMrq/UEc85VpBximD+sEuClCV/brEzdlv/4 x4/ef69PIkZO8PYCR1pYV/j19LtpP3E53rr9mMFgdyVAQ1VKwLL9LePmMiwGgEW16bzU6KyZ+5w uDbYEnf/i8i+MTgeF+SVN043EJBngNS1v+OKDBpd3CV3b9lmUtDEJljNnxntpz3I00yWcNJ5J/5 8t+v3t4gGNuKXKqADhNQkVDHkhiZX0ABVS7YtIz5wJV6ZDVzBFRMvvJNMO2erqCvXsShjLCrTmO U= X-Received: by 2002:a05:6512:1189:b0:5a2:b59a:5e99 with SMTP id 2adb3069b0e04-5a4172e7bdemr14244454e87.22.1777307359417; Mon, 27 Apr 2026 09:29:19 -0700 (PDT) Received: from milan ([2001:9b1:d5a0:a500::24b]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-5a4185ad11fsm8240873e87.14.2026.04.27.09.29.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 27 Apr 2026 09:29:19 -0700 (PDT) From: Uladzislau Rezki X-Google-Original-From: Uladzislau Rezki Date: Mon, 27 Apr 2026 18:29:17 +0200 To: fujunjie Cc: akpm@linux-foundation.org, urezki@gmail.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, shivamkalra98@zohomail.in Subject: Re: [RFC PATCH 0/1] mm/vmalloc: reclaim tail resources on large vrealloc() shrink Message-ID: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Sun, Apr 26, 2026 at 05:28:56AM +0000, fujunjie wrote: > Hi, > > This RFC explores closing the resource retention gap in the vmalloc-backed > shrink path of vrealloc(). > > Today, when a vmalloc-backed allocation is shrunk, vrealloc() updates the > requested size but can keep most of the old vmalloc mapping and backing pages > alive. For sufficiently large shrink operations, this can retain a large amount > of tail resources even though the logical object became much smaller. > > This first RFC keeps the scope intentionally conservative: > > - only ordinary VM_ALLOC areas > - only page_order == 0 allocations > - skip more complex vmalloc object types > - only reclaim tail resources when the retained waste is at least PMD_SIZE > > The current evidence supports this as a resource reclamation fix rather than a > workload-tuned performance optimization. Local validation currently covers: > > - synthetic large shrink correctness > - shrink-then-grow regression > - threshold boundary correctness for the current heuristic > - KASAN run-rootfs vmalloc_oob regression coverage > > I would especially appreciate feedback on: > > 1. whether this shrink direction is desirable upstream at all > 2. whether the initial object-type restrictions are reasonable > 3. whether a conservative PMD_SIZE threshold is an acceptable first heuristic > 4. what kind of in-tree regression test would be preferred > Could you please have a look at this work: https://lore.kernel.org/all/20260420-vmalloc-shrink-v11-0-cad80b00853a@zohomail.in/ Shivam is working on the same feature. Could you please check? -- Uladzislau Rezki