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 C6779C3DA49 for ; Tue, 23 Jul 2024 10:55:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 280F86B0083; Tue, 23 Jul 2024 06:55:51 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 20A126B0088; Tue, 23 Jul 2024 06:55:51 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0844E6B0089; Tue, 23 Jul 2024 06:55:51 -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 DD9936B0083 for ; Tue, 23 Jul 2024 06:55:50 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 84F4D41E01 for ; Tue, 23 Jul 2024 10:55:50 +0000 (UTC) X-FDA: 82370712060.17.2BCE616 Received: from mail-ed1-f51.google.com (mail-ed1-f51.google.com [209.85.208.51]) by imf14.hostedemail.com (Postfix) with ESMTP id 9216E10001B for ; Tue, 23 Jul 2024 10:55:48 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=I9QTb7H2; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf14.hostedemail.com: domain of mhocko@suse.com designates 209.85.208.51 as permitted sender) smtp.mailfrom=mhocko@suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1721732096; 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=pe9A/KmjRfnSqmJTo8amFeX5jdsHC7+ce4ctbtBqkTM=; b=8RqO2C7p7R4fRQQK6Nq1uYjYaxiSo5l1xRXtA28sq3wdrXH08GdVLOz9t8zz3zkZio3f/6 lrMdYvUq0ROTw+fBhsGIRpwYexHTe5pqSn61pa4IAWiAkxFA2pVovuhUzSh8+oPdMsS25U qifVqq6JPJ5u9sXfkFmKtS4d+aNaeCs= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1721732096; a=rsa-sha256; cv=none; b=CaGL8fd28jXe43HCMIS5Pzwshr51T3CfXoAI3kzSuGu7WQTulcVvzDYao8eETuqiVd/Bwi JR/BvtpUiC0j5KXOXVdl9bo9BgLcn+0XeC5YBElUo0cU2ALavgCaixllnKY6loFB9TKXSh 11jHnEpjxUXW1zLLpuH0qFDDsBDffNQ= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=I9QTb7H2; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf14.hostedemail.com: domain of mhocko@suse.com designates 209.85.208.51 as permitted sender) smtp.mailfrom=mhocko@suse.com Received: by mail-ed1-f51.google.com with SMTP id 4fb4d7f45d1cf-5a156557029so4655677a12.2 for ; Tue, 23 Jul 2024 03:55:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1721732147; x=1722336947; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=pe9A/KmjRfnSqmJTo8amFeX5jdsHC7+ce4ctbtBqkTM=; b=I9QTb7H2Bd6U5llN3I81AfK/PjuZU55bYx0sSrL7NjEnr7Sx93oqh2bp+Y1R17jiMu 7OsDcmavbGODTAgeADiX3PoAcZbTCfZxa5OXMy0eZt2llhOxnOTgdVT6RWp/AvL3dmwt OfM1VBoUGM2AfGcsMzq7TaThB6A43RXb182EHbiFoVhu2K3KF1l+pZfi4Ts2tUUi3RxU Bn+jcfpxk+xVZEc09bWfljaGXSl8rgMHYsMadBMLSbhrovu2zJRtCjtXo2Bqo8LBBH7b QH8VeP0sAioj2UVtfS8Ph/0M8YU4+5M1aBRSw9LqjpwdEaBnNUzfOPwwlbGUS1Ecv8eM Rw2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721732147; x=1722336947; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=pe9A/KmjRfnSqmJTo8amFeX5jdsHC7+ce4ctbtBqkTM=; b=Zmu1AfEgzYizjPt/mptsA8y7es/ApUSQ+9V8e9XydQRpGTVLhE5gBmAPP6M3z5ocJQ 2QBK2/e1tgUDsVG7zKgThJAlWzCkIsYVO4WTTFZXfqLu3T8SmnlOjrEdhdFQGSK958wI GveR4n/6QJibOCAvOYRKsvKPXzHtpALwGNQr+8KsnmbhAaxI/5bgb5xmKDh67atDqasK TVjvcwK8RIyNIgSjcRMGt4ypKotrAerDk9y6BHRutDOnIcUu5f1QRxif/2+qHux185mO FXNgu5ohErGqd97qYIe8pSS23hmu8i34YNYOt8sLsJ1WDMN8zfbaqsxWvrjigLOnnEzH 2uLA== X-Forwarded-Encrypted: i=1; AJvYcCXV7kvRObuFVdRNGUr5sg5u1lvn5zpYgHROvj9rq6V2Bl9lX565ygw10QrbuAOwS3OVeHWIhuyLKNoUZLaC7s9PGjw= X-Gm-Message-State: AOJu0Yz3/5cdR6EeU647WaLdrNE4sH5shzBBAfICKQDnqVRLsfqpGCAA ytLwL76pdHguvHIazHuVIPjorEqW5eBp1NTkUFTQt8vgbRR9IDVw5MPAaJoTkCI= X-Google-Smtp-Source: AGHT+IFnu1CtSD7NI8cX8oy1/s1fO3b09mRCXmn4chmnOxeVXYHzEOoS0aY4v6bJfNvEOu6l0cBSsg== X-Received: by 2002:a50:c316:0:b0:5a2:d411:89fa with SMTP id 4fb4d7f45d1cf-5a47b3ce4c4mr5373936a12.36.1721732146651; Tue, 23 Jul 2024 03:55:46 -0700 (PDT) Received: from localhost (109-81-94-157.rct.o2.cz. [109.81.94.157]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-5a30c9beccesm7307633a12.96.2024.07.23.03.55.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 23 Jul 2024 03:55:46 -0700 (PDT) Date: Tue, 23 Jul 2024 12:55:45 +0200 From: Michal Hocko To: Danilo Krummrich 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, hch@infradead.org, kees@kernel.org, ojeda@kernel.org, wedsonaf@gmail.com, mpe@ellerman.id.au, chandan.babu@oracle.com, christian.koenig@amd.com, maz@kernel.org, oliver.upton@linux.dev, linux-kernel@vger.kernel.org, linux-mm@kvack.org, rust-for-linux@vger.kernel.org Subject: Re: [PATCH v2 2/2] mm: kvmalloc: align kvrealloc() with krealloc() Message-ID: References: <20240722163111.4766-1-dakr@kernel.org> <20240722163111.4766-3-dakr@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 9216E10001B X-Stat-Signature: oxo1ktrq13ndww6wteq39gbpxfqsftm1 X-Rspam-User: X-HE-Tag: 1721732148-800433 X-HE-Meta: U2FsdGVkX18R6mtoHVzfeIfrIJE99bGqF0+vzv4h2EFjux4jGKDD0rsPWeckKKnGuKEaNraUDHgW7jPWqEk/xpqfVazeAhGW2olr7J+nCaxcuJi0tJb6BcIQbfQy35RAn0FaPFSjl0pc4nbSa+mkgOTzTTwhwmvbNLXWih1HdNfDYQ0By8QGLO+sCEvuTozfqmRFou/ueAbB04Mysep1nuI118Kq2UvM7YNhB/iA7YcM584gWddvrsLIuG0lrjWGiAg1oCLry9Z2RgoektIIFWWQbTOPNmqDMNmE6BkSsvZEDBV8U1xoAtsW1liTepyeHENMt2mc9d/zlnIcLAbfGE4dhBFs59thCMUO666lP8RViycCX3ldEsmswQidWQrLSNMjrJICGaCb+22jbXB8DZd9EX+OcarSeZ2HTq5rOT0eRCsJLE+5+oZ8PgwoBgCjq7b4VPeaQ113qPKma2guAFa0QaXF4k289Otu0mqZlMcrBs3zC/N6Iifiyc5AEXwVgfIKJYLHOnDSYRVz0OYN2hQsftPttWx56IaF/KiTV7AqkQzLz+zgRN1mMQ9LgZjIJeywZNwbQ5NV1g+jY+H8D3og8GYXn9L8PxT4N8/GruuH2sX2c5x99eKJmyl0lo3T4gLTU/glEc0y+T6TQ+EQvAYfbv0b83oxg7K5i+qLXLZYG6oy9Xdp+DPDeyFWdbYHeQxlxQj1GPjSH3hsDjq9K0cf8cqv/PxRjnK9ojNJBf/y+N0egWaLc+gquOQRWvgVxQHwa+nEpxrMFneuErCW/htv+3HjxQxNzSMrbPBucr1Ub9vXEas83MSpQL6alzFxEa1dd6aj1u20rnHEuGQsN6NWSrM6QPCvAF1k9U3tru95LGpFJGFvtIjbYCj1D2rw5bFb1fxJzZfpPZyg61h5+H8g5rKYyLgZypBA8eTaq+n4BD1kPKB90Ah/NX9g+1XfTj5GTSqbIxvSj6vL+2U eeuJSkJv zIzrHLfjNqGxFpJuEwbybGtjd0Czmurhk6aLB/V/mhvLizqh2GFM/SAK3KbrIROGpiS4mIgvZOyNuq4GpXqVQcd5wuYahXatz48aK2TKY41N0sBzW9RQXI+HKYpFZE0jA8Pjy4zd0Yr+YX+tXskAGHcwK5yoI72++oLKx//kkoE9/IB9FOwKTUxcyHWyBg6acqHtW36qo9YlhvBdNRPlJi5D9uMj4Qb/L2LjcOE9FQ3cPamZc5TazpTSAtWo0GEhVd1Fc3RRYDOqwCF4zwxCQEak5MC5mKVi60a/dFCtQj5wDAmu8zIegNaICp3teVzmUz3sfLo6FGJEErmLEW4ik5/J4TRMJbWOwwkDFziRm/BBqiNk= 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 Tue 23-07-24 12:42:17, Danilo Krummrich wrote: > On Tue, Jul 23, 2024 at 09:50:13AM +0200, Michal Hocko wrote: > > On Mon 22-07-24 18:29:24, Danilo Krummrich wrote: [...] > > > Besides that, implementing kvrealloc() by making use of krealloc() and > > > vrealloc() provides oppertunities to grow (and shrink) allocations more > > > efficiently. For instance, vrealloc() can be optimized to allocate and > > > map additional pages to grow the allocation or unmap and free unused > > > pages to shrink the allocation. > > > > This seems like a change that is independent on the above and should be > > a patch on its own. > > The optimizations you mean? Yes, I intend to do this in a separate series. For > now, I put TODOs in vrealloc. No I mean, that the change of the signature and semantic should be done along with update to callers and the new implementation of the function itself should be done in its own patch. [...] > > > +void *kvrealloc_noprof(const void *p, size_t size, gfp_t flags) > > > { > > > - void *newp; > > > + void *n; > > > + > > > > if (!size && p) { > > kvfree(p); > > return NULL; > > } > > > > would make this code flow slightly easier to read because the freeing > > path would be shared for all compbinations IMO. > > Personally, I like it without. For me the simplicity comes from directing things > to either krealloc() or vrealloc(). But I'd be open to change it however. I would really prefer to have it there because it makes the follow up code easier. > > > + if (is_vmalloc_addr(p)) > > > + return vrealloc_noprof(p, size, flags); > > > + > > > + n = krealloc_noprof(p, size, kmalloc_gfp_adjust(flags, size)); > > > + if (!n) { > > > + /* We failed to krealloc(), fall back to kvmalloc(). */ > > > + n = kvmalloc_noprof(size, flags); > > > > Why don't you simply use vrealloc_noprof here? > > We could do that, but we'd also need to do the same checks kvmalloc() does, i.e. > > /* > * It doesn't really make sense to fallback to vmalloc for sub page > * requests > */ > if (ret || size <= PAGE_SIZE) > return ret; With the early !size && p check we wouldn't right? > > /* non-sleeping allocations are not supported by vmalloc */ > if (!gfpflags_allow_blocking(flags)) > return NULL; > > /* Don't even allow crazy sizes */ > if (unlikely(size > INT_MAX)) { > WARN_ON_ONCE(!(flags & __GFP_NOWARN)); > return NULL; > } I do not see why kvrealloc should have different set of constrains than vrealloc in this regards. > Does the kmalloc() retry through kvmalloc() hurt us enough to do that? This > should only ever happen when we switch from a kmalloc buffer to a vmalloc > buffer, which we only do once, we never switch back. This is effectively open coding part of vrealloc without any good reason. Please get rid of that. -- Michal Hocko SUSE Labs