From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-lf1-f44.google.com (mail-lf1-f44.google.com [209.85.167.44]) (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 0385F3F2110 for ; Fri, 8 May 2026 15:27:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.167.44 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778254058; cv=none; b=XMN7tYVQXbgTdz361Qq0/lKYABZu+yBn/DH1WL0+MQhX1aISiQvnN5CaHhOF+Z0hqxuPHO37VZdlVaycU92YwNNTs296SfdDuJkVjH7rOsB63K5DV8wfXS/14hnMAqwdhzsK59zJQCzBvE7QKH/fCqjKy1bWzncfkIjdjIGFVjA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778254058; c=relaxed/simple; bh=q+ZzsK2lOG1mYurNcjOq8U7Z3ecbM4zf2QCiKXEKWxQ=; h=From:Date:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=GiilNNEow8CEsbUQREeepKAtxGfdVfmjGNbjKc29Adsm6OP55OL+WOAEyMGMK5ncSFBQnsRmkPusJ/TLlhXqZo26p98NRnCUiO5gKw7DnncwpQyY3bLyEk1n6SPTrZ3tiikMr5ocyC4vQ0FLdFtvDFtS4+CfDH0LIvJFrCfpqY8= 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=hAfuIuw3; arc=none smtp.client-ip=209.85.167.44 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="hAfuIuw3" Received: by mail-lf1-f44.google.com with SMTP id 2adb3069b0e04-5a3af1b7549so2592632e87.1 for ; Fri, 08 May 2026 08:27:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1778254054; x=1778858854; 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=EZFhWzWKrY72M1xS0S5a9KeJY9BJfFwwm0awJVZ6bjo=; b=hAfuIuw3qqK+pMGUm1ZCB2GwFLqmeMeIcHUwkxpsnAkcB9MLMqTdOV/bfMhxOOyOYN wwRR/zhC+ytWjpAx7G+P/Lvc/3e/Ds8O9dvofRrVTj99Z65TapPwH7CANyjTw3hb95Wd +3jTSNaUzf3P9vSJ5eQ96CQRtjaECEU/D2Hd3jnhPgcuWkMuN+3frtZqb2Ai31UBIzWB ixy7bx20IF+jgUZHHr1eOEtxRw6aCtcA+Wgc5X0FdckYoiO2hcF9/BS216cFeKTOjGb0 75WxZIuFzvwElcC5jbxVsWzgUFXNa753RCwoZTcsvMxJ4hO6CTu8jBssMxL8XLMcF6Ub SZ+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778254054; x=1778858854; 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=EZFhWzWKrY72M1xS0S5a9KeJY9BJfFwwm0awJVZ6bjo=; b=QsCvh/AURxMiEKf2ir2jr56yg5WENg6Y/ksUIJ+ektjA+ZByBhjSb9IRlpp/lE6524 KHtUIs4ZUm8q/ZRL0IrmUcdY35VsQDwEmYsm0feRW8VUWQYIJfVk2igCFZcE2d6/exLY DjAqUztUcgxyMq9zviYRblbfbbhv/t/VYf2WhYUqsnZA3nwImL5IkCDwJ3T9I9tkelm2 NNMyfZNFiSEpza7EriacfwQZorbiYMg8IEg5iTAlq5xY8AaGT56AlH12loafbfSe5ZjM ES1PY46SOn/OaRjYRnHaTxfORD5Pf0YuWe4l4poQZ1zL6WsC73GE9EuIU2DHDxK5CFaU xF+w== X-Forwarded-Encrypted: i=1; AFNElJ+X11jxume86sTEUA7FVcrvLI7UtihdQxbclTp07LUrMI1tbxju7qcXr+e/kxggS67lO4/xDbQVyPNSxIE=@vger.kernel.org X-Gm-Message-State: AOJu0Yzr5+/h+NdPV5Tk030ZrAuA55H1S8EER7pp1CHdw4ZL9/6Yr9FA sT3MU2sozC3gwDOskMsYwN2LbBixmN0D2OGi4Nw9ThXs8IqVjkoM8+T5 X-Gm-Gg: Acq92OFpGbS0UGAWQLwieAMp8QC1G54o3jtFYSNvyT1O1YgRefrEQF6khgKwY3IM/Hl WLilTxIL5lnCs6qf9UwLQwrb92MiLGxg09CHFBshbJAn9bWnvgiAsNXZ83dBZZTwETI9Kfs+ULx 73k/9kuqUb3sycAm8Tx0Ic2cE76kwip5qLfixOhuLTdqqW0J652Zv5CyWp4mxBX1sMn7FG46R95 LElwZmu5M8c4dKMD1/Q1aV8arPkOaEGpLmgf2QZ960QkQfZ0EKB2/dzQv5xMKAelqPkwFFKS38x cKVtHrxY3nM5U15DoX0vSn8Q8PucbmAmEgcmZzAVQ0Rsbjnh0Ept+2y+2qcgJIM+9YQfCCPwC6g eVHd8O62I1arH4g9eZzDwa+lWEIsxnoQT5di18rGirheZeHrVEeqcxlnafZLIKD/vAd0nhuAtcn Q= X-Received: by 2002:a05:6512:61c2:10b0:5a8:8825:15fc with SMTP id 2adb3069b0e04-5a888251621mr3730986e87.3.1778254052973; Fri, 08 May 2026 08:27:32 -0700 (PDT) Received: from milan ([2001:9b1:d5a0:a500::24b]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-5a8b3e75c31sm86458e87.18.2026.05.08.08.27.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 08 May 2026 08:27:32 -0700 (PDT) From: Uladzislau Rezki X-Google-Original-From: Uladzislau Rezki Date: Fri, 8 May 2026 17:27:31 +0200 To: Shivam Kalra Cc: Uladzislau Rezki , Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Alice Ryhl , Danilo Krummrich Subject: Re: [PATCH v12 2/5] mm/vmalloc: use physical page count for vrealloc() grow-in-place check Message-ID: References: <20260428-vmalloc-shrink-v12-0-3c18c9172eb1@zohomail.in> <20260428-vmalloc-shrink-v12-2-3c18c9172eb1@zohomail.in> 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 Fri, May 08, 2026 at 12:36:18AM +0530, Shivam Kalra wrote: > On 07/05/26 22:51, Uladzislau Rezki wrote: > > On Thu, May 07, 2026 at 01:13:35AM +0530, Shivam Kalra wrote: > > > On 07/05/26 00:17, Uladzislau Rezki wrote: > > > > Maybe we should consider Fujunjie approach and borrow his idea to shrink VA also? > > > > In that case, we do not need to switch to vm->nr_pages? And we do not > > > > need > > > > > > > > [PATCH v12 3/5] mm/vmalloc: use physical page count in vread_iter() > > > > > > > > ? > > > > > > > > -- > > > > Uladzislau Rezki > > > I didn't want to change the va in this patch series and wanted to keep > > > it simple. > > > If we change the va, we will also need to rebalance the rb tree. > > > I can work on a followup patch series if VA space pressure is critical. > > > > > Actually it is not critical. The idea is if we shrink VA then we do not > > need care much about the size thus keeping vread_iter() unchanged as > > well as [PATCH v12 2/5]? at least partly. > > > > I am find with it anyway. > > > > Reviewed-by: Uladzislau Rezki (Sony) > > > > -- > > Uladzislau Rezki > > Thanks for the review. > > There's actually one more benefit of this approach for a future > grow-in-place optimization: since the VA reservation is kept intact > after a shrink, a subsequent grow wouldn't need to allocate a new > virtual address range or manipulate the vmap_area tree. It could > allocate and map new pages directly into the existing VA range. > So for workloads where shrinking and growing occur frequently, > this approach lays better groundwork. > Fair point, so there are pros and cons. -- Uladzislau Rezki