From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out162-62-57-252.mail.qq.com (out162-62-57-252.mail.qq.com [162.62.57.252]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id F244923BD02 for ; Sun, 26 Apr 2026 05:29:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=162.62.57.252 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777181353; cv=none; b=XilQnw3cDP6AW42JykuTwg/AXpbyIkJ34uxmPXuWqCu8O2dm+QQAZN+TeMuqXFa+NFA2X51GtoHcXdWxMdF6udcLdo7JTXOGL9ogpgJZIE6Ix2pM7EFPV+WgBdxtuBE7qgZtfxK4zF6EcRiWCugAvAXswfDnKncUa/AdsrkdC0c= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777181353; c=relaxed/simple; bh=cisbshzvENMjZMmvGgNJkY1SP/6IQ//l96qG8Mr6WTQ=; h=Message-ID:From:To:Cc:Subject:Date:MIME-Version; b=iZNMzIhtY0vaDKvPUwTJ+oJI6N9cVvhSOuVa8vhsjPlFqJuYIUr8Xv5rcQVNK6VlJG5Hzs54XGptXLUUNCnl9kQbmybwjKw+YyeFYxMpGWui8RPy1GZDQqzdVjKJoVfR1me6dc/aXtBTo26X99xAYQ9TmHbYQ2ac/ZU5gtsZo7w= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=qq.com; spf=pass smtp.mailfrom=qq.com; dkim=pass (1024-bit key) header.d=qq.com header.i=@qq.com header.b=kYLA3gHp; arc=none smtp.client-ip=162.62.57.252 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=qq.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=qq.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=qq.com header.i=@qq.com header.b="kYLA3gHp" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qq.com; s=s201512; t=1777181339; bh=fJzK7fYSTENSwy7tb5eInzJUIcvx0OrIylZwUTjYx3o=; h=From:To:Cc:Subject:Date; b=kYLA3gHpU62/rT2nakExAhuZNADlk41miFQQPqw28OcIt9PPhDm/C6XBlCF8xV2g+ vZvPdzfZU1DHOsk25ZRaFsidnIwSex2G5LGLD9nHFG9vbqKziqljG181Q531+vibro xyciBgRY5VHImjjZ0FcHFDqahiOOS+zC0Xgb8fGw= Received: from node68.. ([166.111.236.25]) by newxmesmtplogicsvrszb51-0.qq.com (NewEsmtp) with SMTP id 7391CC41; Sun, 26 Apr 2026 13:28:57 +0800 X-QQ-mid: xmsmtpt1777181337tx3x3duaf Message-ID: X-QQ-XMAILINFO: MMwjR1C73eIssL4KMfUOf3T/tY8xwb1Uz0J+7c1nlVnjDmueEDWiJJpaKsXwRd SMEf/RhCqQQWvyZtJXudSG04zsVabcaJbcqRjRKz8Wb5GKPbMmGh2Fkvuv0felwl3MpOiKPrmykd GdkSAAxv6/zYiLM5vzGm4/CsKs/evYBHO74HwPKWa++xoTxF+ArgLAlhm13QASQbWylGsp6caUGC zk8tfXhgQUdEIpLgmjtKRxbPoqgYqjkjznv2dX3u+qAPgk3G5iGp3jHkUHaDBHCbbiaqeeX5d5RQ zx57G6kM0KiObP5K34jk7+I6hBaQaybEZC7+ddtet1wWYOntW1AaVhfaPhUpDK/C3Z2PWsC0i8UP MGYbptXuGJezmZMkDjW4D4UWT9ZV7LiJyCblVQKufGms1w/gD+P8N6JYoM+V+LtxKdem/h6Zx4uA 9BD7dJW3G9Yc5rZpGClcRv04h+vpgL+6yl7VL8hs9/1axyIUGaRIOxgYxsKUSkXQFjyvRfjy6hN6 mYUvDYKyfR7Keeugy6wEo2ZnRY08FOuaCqA/shtg64r43teM+HwUm6oUD4VzsKa1BkSC1hpUok+V 4jMoYp49Mf+aK728JiVfTZ5p+XlMjU3vXk8ti+/DqROPnztkF8g0oQTloyj5QLRA5ZdzedQvTT1+ P3Z56Q6Wy7tJ5O/RdUJFwyPTpiJBGmE5qv6ZTZgF4orB6DF/Vs/SAvBcVQ1WBa1Fx6BCkqsGpXEg SG4UbCkUH7bPWxb+y8IBfJJgAPyAIAXH3e19NcuXb08RlpT6KXCquKrvsAOxysHuf/6Og4l6NUJ1 G0rLDfb4iFMQP7bx5VJhgUn0Nj10crps93zcIwwXw5xjbw5696CwecXAdlqZAphqmeflnfiVL5++ x3OP7j8qBuc3DBtvLrMwKk0TpFTq+SWpwcx7b+ytI6PA0cPpATYCmBYkKT2pqj8Ay/7kpU6hGrCX +t3AhDCZyvy92szfvGJHKtU4Y7xkck5yp8rLafVLJtPa0BiMes19yHdGIDNQVe94sgm9RLkvepPd IiiV8N3A== X-QQ-XMRINFO: MSVp+SPm3vtSI1QTLgDHQqIV1w2oNKDqfg== From: fujunjie To: akpm@linux-foundation.org, urezki@gmail.com Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, fujunjie Subject: [RFC PATCH 0/1] mm/vmalloc: reclaim tail resources on large vrealloc() shrink Date: Sun, 26 Apr 2026 05:28:56 +0000 X-OQ-MSGID: X-Mailer: git-send-email 2.34.1 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 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 Thanks. fujunjie (1): mm/vmalloc: reclaim tail resources on large vrealloc() shrink mm/vmalloc.c | 105 ++++++++++++++++++++++++++++++++++++++++++++++++--- 1 file changed, 100 insertions(+), 5 deletions(-) -- 2.34.1