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 7051FC2BD09 for ; Thu, 27 Jun 2024 11:05:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DD06F6B00A5; Thu, 27 Jun 2024 07:05:37 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D58456B00A6; Thu, 27 Jun 2024 07:05:37 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BAC446B00A7; Thu, 27 Jun 2024 07:05:37 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 999F76B00A5 for ; Thu, 27 Jun 2024 07:05:37 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 431631C3894 for ; Thu, 27 Jun 2024 11:05:37 +0000 (UTC) X-FDA: 82276387914.30.3270E25 Received: from mail-lj1-f170.google.com (mail-lj1-f170.google.com [209.85.208.170]) by imf14.hostedemail.com (Postfix) with ESMTP id 1F65310000D for ; Thu, 27 Jun 2024 11:05:34 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="GU6Aj/Kj"; spf=pass (imf14.hostedemail.com: domain of usamaarif642@gmail.com designates 209.85.208.170 as permitted sender) smtp.mailfrom=usamaarif642@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1719486318; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=OuPCN0p+/jjkvq2AdK3Vr7mCaGV2v3Y7d+UowOaYEYE=; b=CX4HmOBmPqzMxY7gSRkIOTRrqB/nxFdVhnPI7S425il6RM/ObZeyGvm4CvroSUYJo3ZsA9 9OLDVEjFmU/KwXUEc9/FS1MQESty7RHr7Zv8nxsPse+JzGyNzdEJM8goloziDILnPlqciO 8B9EM6nhNcqQ6/7qYBbXPo9RYdd/TGI= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1719486318; a=rsa-sha256; cv=none; b=kpS3qk17BJNLyI9fNA5F8L1SCqc5Gfe0im9pfrLjceKmMVStbJQCSoxCDwrVBUzAuSxcSh JE3CWCJbQkfF4LP46bqs7PcucTpC1lKop82NqXWedNIZ1KktwjfRGpriIau0ku10xTuOmD XXAmZ/rJQWTDCubhAi47u1boTmmZ6lc= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="GU6Aj/Kj"; spf=pass (imf14.hostedemail.com: domain of usamaarif642@gmail.com designates 209.85.208.170 as permitted sender) smtp.mailfrom=usamaarif642@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-lj1-f170.google.com with SMTP id 38308e7fff4ca-2ee4ae13aabso5404461fa.2 for ; Thu, 27 Jun 2024 04:05:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1719486333; x=1720091133; darn=kvack.org; h=content-transfer-encoding:in-reply-to:content-language:references :cc:to:from:subject:user-agent:mime-version:date:message-id:from:to :cc:subject:date:message-id:reply-to; bh=OuPCN0p+/jjkvq2AdK3Vr7mCaGV2v3Y7d+UowOaYEYE=; b=GU6Aj/Kj3KqD4x8v0pGD+8CpvM+VkCmSbW5T6HdrqkGy+6Z9fM4EFsd70Exxv/x9Tl wyQhSDweCxCadBJkTztHX8Vh8ZgJVuBHxVKo/xjUgK3rfvFQ2gu42qrne8OI1xwLYp83 pFi7Otmm1bkzrcCZIbp0HDL84VPEdHg1VaqglrFY0QWJRcda4nfx0qIF3q47D68cmw53 swM31cMioz/48tGhHSXzC7AfJiAyo4IVcVIZHiRB9jIcSpOPdXBQok8uQnPMfpD4DCUf TLZTcYBe2EmMtXhKCnp5E5/lhp7Zs6PhBitvse90BviOAzo0CaoKtnc5l9/e7o8ywmrs 5/sQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719486333; x=1720091133; h=content-transfer-encoding:in-reply-to:content-language:references :cc:to:from:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=OuPCN0p+/jjkvq2AdK3Vr7mCaGV2v3Y7d+UowOaYEYE=; b=xAB9ciEZgyy6rpNSaGu4bzOxt6US+NlgZ7DoEE/2ivzLpA7VTwOelwCLU9s1NPe9sv SkGnnPISZCA6IGX32M7yX0zDr3VY35W+Fb5p3oT5SBb7Su2wIokxokNX5jOlx8Klcj7i VXQ5qrbyQoGFoXyx97m8g9eoFq6kSBoe+dYohVQVRUuq52374Fm6l/cLi13FJqsiyiGu cMOSuho7MY7VP0cQlYvvmg2B/j2KhVf3MrfxOz+zYkn0EUupZHzeVwuOhfLoIZpSmQ0R wqDGrRoYl5ZwtT3w2LHCKYFH43Q69xIgQwooXyEXoe6D9bfsWBilXPZ0YGWEjcjyfeX/ rarg== X-Forwarded-Encrypted: i=1; AJvYcCWNkKUtd/kSTTkfTe/dZJMlqJXTbbg5cH9DZQ2ZkQsMOqre0/Q90s4n9s8ChZm/POMEd8YZsWtFGG8tGzId7n08qPg= X-Gm-Message-State: AOJu0YykerU9PUzPiYbe07YcVfVqhnz9fpzPV0N2CX5QsBBiE5HYBfM+ vaazrzZIK6L8VXXoHgLFwk6TMnvbYkYT7L+i/A6C8mqH+ScMkIVJ X-Google-Smtp-Source: AGHT+IGWpicF5CW0nfsyxA6FMihNzXykHpD3P/VlaBPhPnHqccGxX3TRaC1MfI9a7OuvOaoI3J10Dw== X-Received: by 2002:a2e:8297:0:b0:2ec:174b:75bb with SMTP id 38308e7fff4ca-2ec5b38ad36mr76185751fa.28.1719486332948; Thu, 27 Jun 2024 04:05:32 -0700 (PDT) Received: from ?IPV6:2001:16a2:df29:7e00:184b:b632:a7dc:1c99? ([2001:16a2:df29:7e00:184b:b632:a7dc:1c99]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-42564b65637sm21293475e9.12.2024.06.27.04.05.30 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 27 Jun 2024 04:05:32 -0700 (PDT) Message-ID: <159061bc-27b5-4127-a85d-223bed0ddfd5@gmail.com> Date: Thu, 27 Jun 2024 14:05:29 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [linux-next:master] [mm] 0fa2857d23: WARNING:at_mm/page_alloc.c:#__alloc_pages_noprof From: Usama Arif To: Yosry Ahmed , Hugh Dickins , Yury Norov , Rasmus Villemoes Cc: kernel test robot , oe-lkp@lists.linux.dev, lkp@intel.com, Linux Memory Management List , Andrew Morton , Chengming Zhou , Nhat Pham , David Hildenbrand , "Huang, Ying" , Johannes Weiner , Matthew Wilcox , Shakeel Butt , Andi Kleen , linux-kernel@vger.kernel.org, "Vlastimil Babka (SUSE)" References: <202406241651.963e3e78-oliver.sang@intel.com> <12fb19d1-3e57-4880-be59-0e83cdc4b7f1@gmail.com> <61d19ec8-2ba7-e156-7bb7-f746dae8e120@google.com> <5b3e732c-d23d-41ef-ae5c-947fa3e866ab@gmail.com> <167b2f11-a013-440f-b196-5d8c0ea5d9b3@gmail.com> Content-Language: en-US In-Reply-To: <167b2f11-a013-440f-b196-5d8c0ea5d9b3@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Stat-Signature: wmhnp5cwf9tynz653w3r6mypi4x7qdhn X-Rspamd-Queue-Id: 1F65310000D X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1719486334-116173 X-HE-Meta: U2FsdGVkX18jUEH6ftwEzGAbZB3Mt4NL5Hu8/JR762A7MHjB7qyRknBGgvikrSauTwmYDagXfQPgPtdVVBCiW6EUfUwAkdHP+KWQmOKMcOmqfgqzrQeKktxynVjfT0fYpnZAiTZBC7N2gSEiWCpCJzhHzTvmUxQm0bI7uE765Ny3Q4EH2pNZY5HulLYptbrrVHZmvK1oxIpdbarH6e890JiXOYs7a2Qqhe/SvX1OdZ5SWo4ORp1+kfNKCmmhxxFM8hx6cqmYu6gFiQJKhCzLOBD8m3RA+rNUzjTKhX9GnyDvmfhgy+WTeATZMG9k31KPkZbnaefSXAKqrFp0pxiBSdZJEnfvCy1lWsnioLdDju+NDbkXiiZo8u+DUCIwk/Z2oGc4INn8miMmxIB6NYApAghnH/k1AmZPUpduqBiQz7DzjyJ1BZ+Y4owxYRL1c1e0EbIRVTCxrUtl5Gu1Z400S/fc404w5/0k9yA39dr1WbP/x62dw+tDTt3oIJIigfhbx8b4yxqEqzgwa7TCwqW0QYQVaQZCK9Bw66H7MBJXF+9tWSV++8wWEuBFT3RA2KRz3GyTL/GDqvRqYf+wM9U0rCPdcQCcmAvXaZbvOWtEXGgJetg6SSA3bI2tA/3IMThEfhfFsRvROTpY7dg/lOF/lGZl+smh8KQrpaoQ99D98Lc1PZvveCKx9nY3McF+NRBRpNdWMTwaMsRJ5sShx5IWi3aALGx9WcU3qIHk5nHgSO+54rPFaAk38slMOKTaGSBSXd3AgS+diRoI/r79ggKDa6d1J/QgUXP6amccLddGdD2/DL4e17vjei5RH05NcUw1UF9xT7uh608pxvDlYTabl7ljedAAV7UfCuSnLhRh0cquR+u6+IBHxr3hOzwxbqwv6mz5dnaGVcXsuNjGnWQlj6q4cJrUH7LFR37q45QRv+/TcF96d28PbH5k1PWb5xbuXCDuBf8lxdAPRvQlNK7 nVkelAgZ TFh99k7SjrGwZQY4hbf/msUQCpaMgbM743Wlehweo1K5oeaqkVGvTvShIlnHmzLo5ArxTHJpThDRgZ+Gst22ZFU+2iMLJufGG5IEZQn9BvKd40j9kO8+2Es/PSYzTuNyrAoIvd+KXAAaDFIEBKMAWOpGdHBtfkcxQRhbaxP92yyYnPCY2LWs8eKWC2i8RF8fq2URxfiME8XK8n7hhwCBOHOE7tDwDQlYKHOW6GD9mYMl1p2KZFG6tgnz3aWDSfn44V/1QXeKROlpT/eW41s03AaNgAbnPtg/geisD0w4N9keec4e13XVwpfpsTMxUyyr3PkSbyk/i0VgZ1ulSRLeYprSwQMa7XcRIUSII170dv4h2qHmcmoAg8B+AsTxsSmjjkxtC62dtCKz5wBSOJI2KfeQXIMlSyeMknNvTRuzIIxeQIiUM8/qF+65arh9ysrqYQvQXRcJoUaxAW6lEZps/09j8CjSyhHlmZ1F+bFfb0ObalKs2HQmXxPN45DFhb4RVDrVdA2EUhUxvKjzA8Pf3koRI+ctpsqfeUz6DSo0QNYWxs1aZpYUR7gUc8n8hs4JsmSyNQppVwq2P9fzJUVF3wjBMPS2o/0VsiwDx4/nm3D8w06MnhBDksFt5fSMYdpYfgHUi 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 24/06/2024 21:26, Usama Arif wrote: > > On 24/06/2024 20:31, Yosry Ahmed wrote: >> On Mon, Jun 24, 2024 at 10:26 AM Usama Arif >> wrote: >>> >>> On 24/06/2024 19:56, Yosry Ahmed wrote: >>>> [..] >>>>>>> -       p->zeromap = bitmap_zalloc(maxpages, GFP_KERNEL); >>>>>>> +       p->zeromap = kvzalloc(DIV_ROUND_UP(maxpages, 8), >>>>>>> GFP_KERNEL); >>>>>> No, 8 is not right for 32-bit kernels. I think you want >>>>>>         p->zeromap = kvzalloc(BITS_TO_LONGS(maxpages), GFP_KERNEL); >>>>>> but please check it carefully, I'm easily confused by such >>>>>> conversions. >>>>>> >>>>>> Hugh >>>>> Ah yes, didnt take into account 32-bit kernel. I think its >>>>> supposed to be >>>>> >>>>>     p->zeromap = kvzalloc(BITS_TO_LONGS(maxpages) * >>>>> sizeof(unsigned long), >>>>> GFP_KERNEL); >>>> You can do something similar to bitmap_zalloc() and use: >>>> >>>> kvmalloc_array(BITS_TO_LONGS(nbits), sizeof(unsigned long), GFP_KERNEL >>>> | __GFP_ZERO) >>>> >>>> I don't see a kvzalloc_array() variant to use directly, but it should >>>> be trivial to add it. I can see other users of kvmalloc_array() that >>>> pass in __GFP_ZERO (e.g. fs/ntfs3/bitmap.c). >>>> >>>> , or you could take it a step further and add bitmap_kvzalloc(), >>>> assuming the maintainers are open to that. >>> Thanks! bitmap_kvzalloc makes most sense to me. It doesnt make sense >>> that bitmap should only be limited to MAX_PAGE_ORDER size. I can add >>> this patch below at the start of the series and use it in the patch for >>> zeropage swap optimization. >>> >>> >>>       bitmap: add support for virtually contiguous bitmap >>> >>>       The current bitmap_zalloc API limits the allocation to >>> MAX_PAGE_ORDER, >>>       which prevents larger order bitmap allocations. Introduce >>>       bitmap_kvzalloc that will allow larger allocations of bitmap. >>>       kvmalloc_array still attempts to allocate physically >>> contiguous memory, >>>       but upon failure, falls back to non-contiguous (vmalloc) >>> allocation. >>> >>>       Suggested-by: Yosry Ahmed >>>       Signed-off-by: Usama Arif >>> >> LGTM with a small fix below. >> >>> diff --git a/include/linux/bitmap.h b/include/linux/bitmap.h >>> index 8c4768c44a01..881c2ff2e834 100644 >>> --- a/include/linux/bitmap.h >>> +++ b/include/linux/bitmap.h >>> @@ -131,9 +131,11 @@ struct device; >>>     */ >>>    unsigned long *bitmap_alloc(unsigned int nbits, gfp_t flags); >>>    unsigned long *bitmap_zalloc(unsigned int nbits, gfp_t flags); >>> +unsigned long *bitmap_kvzalloc(unsigned int nbits, gfp_t flags); >>>    unsigned long *bitmap_alloc_node(unsigned int nbits, gfp_t flags, >>> int >>> node); >>>    unsigned long *bitmap_zalloc_node(unsigned int nbits, gfp_t >>> flags, int >>> node); >>>    void bitmap_free(const unsigned long *bitmap); >>> +void bitmap_kvfree(const unsigned long *bitmap); >>> >>>    DEFINE_FREE(bitmap, unsigned long *, if (_T) bitmap_free(_T)) >>> >>> diff --git a/lib/bitmap.c b/lib/bitmap.c >>> index b97692854966..eabbfb85fb45 100644 >>> --- a/lib/bitmap.c >>> +++ b/lib/bitmap.c >>> @@ -727,6 +727,13 @@ unsigned long *bitmap_zalloc(unsigned int nbits, >>> gfp_t flags) >>>    } >>>    EXPORT_SYMBOL(bitmap_zalloc); >>> >>> +unsigned long *bitmap_kvzalloc(unsigned int nbits, gfp_t flags) >>> +{ >>> +       return kvmalloc_array(BITS_TO_LONGS(nbits), sizeof(unsigned >>> long), >>> +                             flags | __GFP_ZERO); >>> +} >>> +EXPORT_SYMBOL(bitmap_zalloc); >> EXPORT_SYMBOL(bitmap_kvzalloc)* > > > Actually, does it make more sense to change the behaviour of the > current APIs like below instead of above patch? Or is there an > expectation that the current bitmap API is supposed to work only on > physically contiguous bits? > > I believe in the kernel if the allocation/free starts with 'k' its > physically contiguous and with "kv" its physically contiguous if > possible, otherwise virtually contiguous. The bitmap functions dont > have either, so we could change the current implementation. I believe > it would not impact the current users of the functions as the first > attempt is physically contiguous which is how it works currently, and > only upon failure it would be virtual and it would increase the use of > current bitmap API to greater than MAX_PAGE_ORDER size allocations. > > Yury Norov and Rasmus Villemoes, any views on this? > > Thanks > > diff --git a/include/linux/slab.h b/include/linux/slab.h > index 7247e217e21b..ad771dc81afa 100644 > --- a/include/linux/slab.h > +++ b/include/linux/slab.h > @@ -804,6 +804,7 @@ kvmalloc_array_node_noprof(size_t n, size_t size, > gfp_t flags, int node) >  #define kvcalloc_node_noprof(_n,_s,_f,_node) > kvmalloc_array_node_noprof(_n,_s,(_f)|__GFP_ZERO,_node) >  #define kvcalloc_noprof(...) kvcalloc_node_noprof(__VA_ARGS__, > NUMA_NO_NODE) > > +#define kvmalloc_array_node(...) > alloc_hooks(kvmalloc_array_node_noprof(__VA_ARGS__)) >  #define kvmalloc_array(...) > alloc_hooks(kvmalloc_array_noprof(__VA_ARGS__)) >  #define kvcalloc_node(...) > alloc_hooks(kvcalloc_node_noprof(__VA_ARGS__)) >  #define kvcalloc(...) alloc_hooks(kvcalloc_noprof(__VA_ARGS__)) > diff --git a/lib/bitmap.c b/lib/bitmap.c > index b97692854966..272164dcbef1 100644 > --- a/lib/bitmap.c > +++ b/lib/bitmap.c > @@ -716,7 +716,7 @@ void bitmap_fold(unsigned long *dst, const > unsigned long *orig, > >  unsigned long *bitmap_alloc(unsigned int nbits, gfp_t flags) >  { > -       return kmalloc_array(BITS_TO_LONGS(nbits), sizeof(unsigned long), > +       return kvmalloc_array(BITS_TO_LONGS(nbits), sizeof(unsigned > long), >                              flags); >  } >  EXPORT_SYMBOL(bitmap_alloc); > @@ -729,7 +729,7 @@ EXPORT_SYMBOL(bitmap_zalloc); > >  unsigned long *bitmap_alloc_node(unsigned int nbits, gfp_t flags, int > node) >  { > -       return kmalloc_array_node(BITS_TO_LONGS(nbits), > sizeof(unsigned long), > +       return kvmalloc_array_node(BITS_TO_LONGS(nbits), > sizeof(unsigned long), >                                   flags, node); >  } >  EXPORT_SYMBOL(bitmap_alloc_node); > @@ -742,7 +742,7 @@ EXPORT_SYMBOL(bitmap_zalloc_node); > >  void bitmap_free(const unsigned long *bitmap) >  { > -       kfree(bitmap); > +       kvfree(bitmap); >  } >  EXPORT_SYMBOL(bitmap_free); > I decided to go with just using simple kvmalloc_array for v7 [1] with __GFP_ZERO instead of adding a new API to bitmap or changing the existing API to kvmalloc/kvfree as I didnt want to make this series dependent of bitmap API changes and there are other places where its done using kvmalloc_array like ceph and ntfs3. I am happy to send a follow up patch after this series that changes the existing API to be kv if thats something the bitmap maintainers think makes sense. [1] https://lore.kernel.org/all/20240627105730.3110705-1-usamaarif642@gmail.com/