Re: [PATCH v12 1/4] mm/vmalloc: allow to set node and align in vrealloc
Alexei Starovoitov <[email protected]>
| Newsgroups | org.kernel.vger.linux-bcachefs,org.kernel.vger.bpf,org.kernel.vger.linux-kernel,org.kernel.vger.rust-for-linux,org.kvack.linux-mm |
|---|---|
| Message-ID | <CAADnVQ+qCNfm3aucBrkXRXrUjjYeYQb09Oobx+pgOXNDny4s8w@mail.gmail.com> |
On Wed, Jul 9, 2025 at 3:57 PM Danilo Krummrich <[email protected]> wrote: > > On 7/10/25 12:53 AM, Alexei Starovoitov wrote: > > On Wed, Jul 9, 2025 at 10:25 AM Vitaly Wool <[email protected]> wrote: > >> > >> > >> -void *vrealloc_noprof(const void *p, size_t size, gfp_t flags) > >> +void *vrealloc_node_align_noprof(const void *p, size_t size, unsigned long align, > >> + gfp_t flags, int node) > >> { > > > > imo this is a silly pattern to rename functions because they > > got new arguments. > > The names of the args are clear enough "align" and "node". > > I see no point in adding the same suffixes to a function name. > > In the future this function will receive another argument and > > the function would be renamed again?! > > "_noprof" suffix makes sense, since it's there for alloc_hooks, > > but "_node_align_" is unnecessary. > > Do you have an alternative proposal given that we also have vrealloc() and > vrealloc_node()? vrealloc_node()?! There is no such thing in the tree. There are various k[zm]alloc_node() which are artifacts of the past when NUMA just appeared and people cared about CONFIG_NUMA vs not. Nowadays NUMA is everywhere and any new code must support NUMA from the start. Hence no point in carrying old baggage and obsolete names.