From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-lj1-f176.google.com (mail-lj1-f176.google.com [209.85.208.176]) (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 79EBB34C98C for ; Mon, 27 Apr 2026 17:07:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.176 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777309653; cv=none; b=rsf4HrWry/uTcUWdr0iIPTGJQEZzU48C9P61L75bagk2pBMCeL9KUdusI9zFzA4QSOf20zFm/uC+6Xl3CEDBCRcsBFus7DWA+sWaZn6EIvgGc9oZwYraCIbu3kYVfBTIUcAW3eb0/k4EVhR90D6dhhdFq1eWW5drpuMsNxCA9Gw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777309653; c=relaxed/simple; bh=R0LjK+o0t1GB+TNwK5fta9tFGvN9t3xjRtGsUjQvEDQ=; h=From:Date:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=snF4+DyRRbg0f4OBWxTwt2mn3duhg2pmY+Ays+RxLrUFwf8PJb5UgshABmSITyvIZLWmS2fHQZce7+uEGXqtvHoL4MiNTwMxwg9gdwQAU22uwB776ZW5SXw1s0CkaTh6V+AxbY5Fh3iOoTCuZiTkohHPAckPyYu5tqRBxA16baw= 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=hyE3vVly; arc=none smtp.client-ip=209.85.208.176 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="hyE3vVly" Received: by mail-lj1-f176.google.com with SMTP id 38308e7fff4ca-38ce0ab821cso89492561fa.0 for ; Mon, 27 Apr 2026 10:07:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1777309651; x=1777914451; 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=4MmHCQR7YEWlANzQuL8DvPtYL+oesU9JFoQ7/o//1T8=; b=hyE3vVlyKpIey0xUgprwKN1TJuiuH2jGFPUkIp4QCJNdUrDwA1uPOfspVm6w36iCdo Q4oiOCT1dgmv8DvmzwY75Pe2YiH/UHkUUHFQJXoUHJ68aQ7ZUEXJSmLTN8pd8l+I0EpM wzM2RPyb5/FQZBdYhyvObeq6tp690/GEf2oXVhWCFAcSwEYIGt4bLuL5j4Mri6wwGU/J c/7pPAPlIjg3IH3JjKuKoZ0n/i1su7KcqqvkLBgJACskTb/03pZvEyABdWE4SmE5jif1 I4BzwQayUCkxDCmypQCtr6hC3zmPRn6KzomXjtvN7JTrtr1CQ0YybrU5O6R0pVZ1pYeB Ev7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1777309651; x=1777914451; 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=4MmHCQR7YEWlANzQuL8DvPtYL+oesU9JFoQ7/o//1T8=; b=Vj9jR9aoYLgHmogyskOVs5miUNbml89faA1zn6rGhJi/rEJFAvyoYskDy9hComL9u3 jaP0y86uIshcxt+nHmDghgK1DSxRR58/DeROzuX9yTUILcgyWSc5Ij5lfXAIi0558+l5 zayYe7iU4ZQGGD4D0MyTNJwPy7ngQ4zfEzJ06rkvVppxP4ftOCqr7BzDIpYiEE9BB3Hi S/uwlISNWt2u9yHRwSO4qtfJ4ehBtLfmuYRne3JlmKdqO4Dp2uW8R1yim/fu3J0Zq5VU b4a35CLCvYlqObWlk7r32VyCl4di4RS2nmTIFBJlv9JQ7NB8Wf+hOh5Tf8nBn2GLJOry Shmg== X-Forwarded-Encrypted: i=1; AFNElJ9WCZYPfLkmZmb19vJjvePOpB8QixQo7qum2+UEQBh+SS2b2og6YD5EhnarHQhuu+mk29WfST9h1ZAN3z0=@vger.kernel.org X-Gm-Message-State: AOJu0YzJ958m9QyywzjBYvdDMA019n22V7R80w02f7I+aZ9K9VTBW0nZ kgIHz3bqRDcdwTb1ZNBsfD34c4mow9rAJ9BpJLMrMBSCazYzw9hQxZ5nNpkEgcJ9 X-Gm-Gg: AeBDiesv33Yr7Y7KEdxtWvqj+wc0lHuGK6l1A+L81PXpw+EQV7lFseV+hsuZB6y+hMi /421+rEX0Lx/MGjRiWRblulDBtiVVXUc1yi73JyIYGa0t7OD/EfSai8xIVjLVKaqu++q57owUAx Y3f/9lqDKusYiIG/+d8rPkOdIhH4UdWD0fii0oLQldcQKgWhr1s0UEnIVaLhfx5g8Mr0BMJgJ1Y zNUWS2H513at7JbDkNb7t9dkVZJTBuSWEx+/lBgcSpPIFkbOUpxCH50PefvJphgxuJAk0cQOiy7 bNuKlX1L52WR9ROdqC6VTGPfRMRMWcK5cE0dNxk8cmvfgUhfe/iVG/3J1yfYjQDsE/m8GDvJ3fY r8C7mPzVCGgAQHmEitgDPk8HlVZC+9OkuYGEl0Aj81rZLITQw3vd9n5mL4S01/im2C4MKN3nEM2 k= X-Received: by 2002:a05:6512:10c4:b0:5a2:b59a:5e99 with SMTP id 2adb3069b0e04-5a745f55728mr36284e87.22.1777309650322; Mon, 27 Apr 2026 10:07:30 -0700 (PDT) Received: from milan ([2001:9b1:d5a0:a500::24b]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-5a4185c8a33sm8502814e87.36.2026.04.27.10.07.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 27 Apr 2026 10:07:29 -0700 (PDT) From: Uladzislau Rezki X-Google-Original-From: Uladzislau Rezki Date: Mon, 27 Apr 2026 19:07:28 +0200 To: Fujunjie , shivamkalra98@zohomail.in Cc: Uladzislau Rezki , akpm@linux-foundation.org, 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 Tue, Apr 28, 2026 at 12:38:59AM +0800, Fujunjie wrote: > > > On Tue, Apr 28, 2026 at 00:29, Uladzislau Rezki wrote: > > 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 > > Thanks for the pointer, and sorry for missing Shivam's series before sending this RFC. > > I will read through it first and avoid duplicating the effort. > Thank you! Maybe Shivam can also have a look at your work. I put him into To. -- Uladzislau Rezki