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 B5305C3DA49 for ; Thu, 18 Jul 2024 11:44:02 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3F5066B0096; Thu, 18 Jul 2024 07:44:02 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 37DDD6B0098; Thu, 18 Jul 2024 07:44:02 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 250506B0099; Thu, 18 Jul 2024 07:44:02 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 05DAC6B0096 for ; Thu, 18 Jul 2024 07:44:01 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id A49E2419CF for ; Thu, 18 Jul 2024 11:44:01 +0000 (UTC) X-FDA: 82352689482.08.32F5057 Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by imf16.hostedemail.com (Postfix) with ESMTP id 96ED0180024 for ; Thu, 18 Jul 2024 11:43:58 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=OlnHvgg7; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf16.hostedemail.com: domain of dakr@kernel.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=dakr@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1721303008; a=rsa-sha256; cv=none; b=V7WGg5UoxqbpsNVkteqfu8qntD0jqWzyFv0U+AXZ6PP2CmE/JEDh62RFMPlYa5bPwJLIGh xtLZQywsjyXpwBPITgTc6fGRr4Xpz4MP4Q7Q3OqTZaHHcis2DoMfQQA30771rZ0fRnt6VL 9bHbp3plD3SrEqngSIZm/2/udlVDBsU= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=OlnHvgg7; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf16.hostedemail.com: domain of dakr@kernel.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=dakr@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1721303008; 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=d347yYZ9CILpxpsu2q6yXF4se6PKyeo/GYV5XBTR8yw=; b=bBZP5vcr4fwLVHsLVmiGDpCeKmQ0jneUC8F+QOr5X1FjNkkkYrLC91NEZGbEg2QmRDz7XM p55s5qkkagKiqNUa6eQq6kOrDirlRNkGYyMi9sUHI3zxZKgcB3o/WBOu6wQKLhwMz2smlt QEeJo3l3lyDReptQhk2y0jXqxdzrW/A= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id 113CCCE193D; Thu, 18 Jul 2024 11:43:55 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5FAFFC116B1; Thu, 18 Jul 2024 11:43:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1721303034; bh=j9ZM4sgimbHCwOKSnNzbQnPlbO19lzIBOmXEFXAmSnQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=OlnHvgg7IhAplaec55DHHogreodz3snoybUI8HGsD6Y2AX0c5c0YiPTbHAdKn/gv9 Mnsw9q0T2OD31mYN231jIB0nqFMwuIGuuG+CE3mjF0Fz3wUUivANeJwAZkAfqDVtRM DpphTzSuVLwIJGSDqPg6Gvu60XqSYpePH1+2t8scTSFKkjriIfP0GQ7FmZHvRBSFC3 9RukZp7VQIi48hQjjyr6C37785Yuwde20Wj0eFj7uRZF8QXzpta/ebSjOl3qXVhaId /KoisvMi9PVwgjlVPYsUnr2300x8D8utnnGUFpTtKXbUB+Bzo7zU31cvvzD27DVyjK Qhk08nEJGnMUw== Date: Thu, 18 Jul 2024 13:43:47 +0200 From: Danilo Krummrich To: Christoph Hellwig Cc: cl@linux.com, penberg@kernel.org, rientjes@google.com, iamjoonsoo.kim@lge.com, akpm@linux-foundation.org, vbabka@suse.cz, roman.gushchin@linux.dev, 42.hyeyoo@gmail.com, urezki@gmail.com, kees@kernel.org, ojeda@kernel.org, wedsonaf@gmail.com, mhocko@kernel.org, mpe@ellerman.id.au, chandan.babu@oracle.com, christian.koenig@amd.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, rust-for-linux@vger.kernel.org Subject: Re: [PATCH 1/2] mm: vmalloc: implement vrealloc() Message-ID: References: <20240717222427.2211-1-dakr@kernel.org> <20240717222427.2211-2-dakr@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 96ED0180024 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: d43ecjfifm6a4fcqcyght6ukcz1p6py4 X-HE-Tag: 1721303038-766284 X-HE-Meta: U2FsdGVkX1+oTZufH/dVMRtRRcmBXtuMOTL3itN74Ea0iGtQmwOorHF3nUaYtTtdj1JZPfDqixvxjaZNSBbkj/PAl1n4Y+eVtMufiWEflFa6A8aQru/9cuB7yM3aYYOhY5fZupNI+1m7u3Efmv6KDLVlN28PdwYB/fxEXH68WKGyndzxaTSLTTw7jXOdbBlAtBJiLacSVtrPVG0+d4gBYsF5NkKmQmNYjhQzSQZtwAOGOL3Rl3LkGgWt2r4uIhbTm+GijTGepTLiWdahgYPkPuJHeDToc+PRNlxU5e5D6ArsPYeF9txIJ8H+15he31CwNQ7kYMkgG5dvutt4hjvpC3+GTxlZuqf4woUJK1DSUxPTkqnukW6BPUCxvLbAJFc/wGDGz892yS0cCIWq246ThGLP5CqEcJOHzcUIM/DFfAfAuOZgJxH5juY62FzTXnEgX2Ej5qZbocDBQ9yMaPq8yzY0mxYV3in9mXzcTGXbuTZCLD5uD45theSw+ozagKhssOxwdLAoDFhSJthEYlLhbLYECMPUS2Blxa2j+JcA/ZWR1IfRWYfKG1kwtxX28PRAmmFrvEU59vGnnARPwTgRQIiX8OLuyUurH5PfEQ4O0mfUCCSailWBjvG27hNBAswrq3I0yfaIzbsbCmum+A3Bno+P8e8p5SyBYzKb+TfZgRAc6yv3DnVfWHsdSjfPNCxWIpbkV7uqfjzvJiwQPiJ9C6oSwwhuM75miok3tqjyspNR1WbglyrosVwdMNRiDNglIrH60aqSWN7VFYk0ert3HMHpkuy7K+8lQkwuORYukGeg4CuedYYl93/y4TpqLLyxXIApbv/j9CK5kNSXds2gx8eUYbPSiR2ddF2KRbFSzkqoVU1IHEcGcAlmEGG3mf4ag97e5vJnAaekO9Noi7cD6tS2otj8SrHSWTweYatGuTxVarJFQ5bcUoMrmBhZPZe+6CkyHQABE0dDea+cgq1 RNjlWqFn HKBBFq8c8GkTisWpxJ/tYY53mu6kPBOub2xXl/7QbtGPwfBaFxZffe0RW3vKXeMqWkStpTo9vtyn9t0QGmLZOxGjxdKDtYk7IxZO8w43mcOuQR22n39TfEvHE0+Z4H54TVwjVKThlmVuTWYEFWyZvn/Qr9WtYPOzqjv9N46K5omjQ6vpBt3nbI/S9lVeuFpsEdvCxF23yCOfoDRUGFrdlkFdDflnwl1/+pMR//G0nhHkYzcUsPA4iRTAp8SjPfYiEcSsPpJ4B9RTIsIWUBeUYxDLceP+ogienEUrz X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, 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 Wed, Jul 17, 2024 at 08:16:29PM -0700, Christoph Hellwig wrote: > On Thu, Jul 18, 2024 at 12:24:01AM +0200, Danilo Krummrich wrote: > > +extern void * __must_check vrealloc_noprof(const void *p, size_t size, > > + gfp_t flags) __realloc_size(2); > > No need for the extern here. > > It would also help readability a bit to keep the __realloc_size on a > separate like, aka: > > void *__must_check vrealloc_noprof(const void *p, size_t size, gfp_t flags) > __realloc_size(2); Sure, will change that. > > > + if (size <= old_size) { > > + /* TODO: Can we optimize and shrink the allocation? What would > > + * be a good metric for when to shrink the vm_area? > > + */ > > Kernel comment style is to keep the > > /* > > on a line of it's own. I think it differs a bit throughout subsystems - will change. > A realloc that doesn't shrink is a bit pointless. Indeed - the idea was to mostly clean up kvrealloc() in this series first and implement proper shrinking and growing in a subsequent one. Does that make sense? > The same heuristics as for krealloc should probably apply > here, adjust to the fact that we always deal with whole pages. Sounds reasonable, but are there any? In __do_krealloc() if ks > new_size we only call into kasan_krealloc() to poison things and return the original pointer. Do I miss anything? > > > > + /* TODO: Can we optimize and extend the existing allocation if we have > > + * enough contiguous space left in the virtual address space? > > + */ > > I don't understand this comment. I meant to say that we could optimze by allocating additional pages and map them at the end of the existing allocation, if there is enough space in the VA space. If that doesn't work, we can still allocate additional pages and remap everything. > > > +EXPORT_SYMBOL(vrealloc_noprof); > > New interfaces should be EXPORT_SYMBOL_GPL. That being said for this > to be added an exported we'll need an actual user to start with anyway. Besides kvrealloc(), the Rust abstractions will be a user soon, but for that we probably don't need the export either. I will remove it for now.