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 79780C3DA7F for ; Thu, 15 Aug 2024 18:48:08 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1466C6B01B3; Thu, 15 Aug 2024 14:48:08 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 11E1F6B01F0; Thu, 15 Aug 2024 14:48:08 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F27B26B01F1; Thu, 15 Aug 2024 14:48:07 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id D31EA6B01B3 for ; Thu, 15 Aug 2024 14:48:07 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 8798AC16E5 for ; Thu, 15 Aug 2024 18:48:07 +0000 (UTC) X-FDA: 82455364614.20.BF94635 Received: from mail-wm1-f47.google.com (mail-wm1-f47.google.com [209.85.128.47]) by imf19.hostedemail.com (Postfix) with ESMTP id 84CA71A001B for ; Thu, 15 Aug 2024 18:48:05 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=QCxBe3yr; spf=pass (imf19.hostedemail.com: domain of usamaarif642@gmail.com designates 209.85.128.47 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=1723747649; 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=GMuOj9Mdm0JKv0Lrfny/0hBubHJ6XoibClFzab+wqoA=; b=mZyaqe81+rrmJEK2cvD+rsmQpOB+375kyEhIVUoZjqrwCIJ3Bt0l2ouCfwYUa888YSpbNZ /Lop1y6v7v13qfSHh0UQqA1BPYXgV6eS9ClsVoIYgaM017CAUNShI4CpvZR0zpXUUC/d+e Qt+eKNOeGPrU5kb+WfvQNJ7XH/wRLdo= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=QCxBe3yr; spf=pass (imf19.hostedemail.com: domain of usamaarif642@gmail.com designates 209.85.128.47 as permitted sender) smtp.mailfrom=usamaarif642@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1723747649; a=rsa-sha256; cv=none; b=iVB4OlLPxLGlDY5zFOFw2Buy/15Qmk7610mCW8p8VUf7/GDEBaIIkDXMJMRtfUn80KhEP+ D/pXkCgTfh9k3tZgbZ7D0+vcgnMNCvkSabyMucvWTBVRcQJHTVKpPwzld0VtrOhWowiZoQ Iu/wUgnllvZEumn98JGXBiUxD3U+ojI= Received: by mail-wm1-f47.google.com with SMTP id 5b1f17b1804b1-42816ca782dso8622395e9.2 for ; Thu, 15 Aug 2024 11:48:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1723747684; x=1724352484; darn=kvack.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=GMuOj9Mdm0JKv0Lrfny/0hBubHJ6XoibClFzab+wqoA=; b=QCxBe3yr/eVjdbxVDfwUXexkSoGHWnhwU9GhSYDXdr2q5PdNGv5JC40vFwKCP8BSda y/js6rdd6TnCw87ygmxLZDpTSGs8tVPKNcmpj4HyDOxAWpBEWdxFQWqLSM5mOfDRWB3d znkMg5HHKl54a0gkYuyGj3wN+VKTOtO5A+6sGp4ayeUb5B0iBJdX6tbR9EYsmzUB6VFU 8Heao0bwKPRWVNiO3OJfusD8r4x09s55RLa76etYQ6Md8ogWR+xXYzhFrc1dwwivC63n gkrJXAWcFx8K8Tqv2c9dHOB/SQ/47ajfnG91W8Z8bazLb1sx4Rd6jE9adv992VvMSWjh 8XYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1723747684; x=1724352484; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=GMuOj9Mdm0JKv0Lrfny/0hBubHJ6XoibClFzab+wqoA=; b=s3sLRuR73NLmuCWkrh4O9QESi+zCZuI+R3DisUg5iwLzZB6USwBO8nZQQlOeDsT74I eYaOmEmVYCKmgn6eKifNw6SVe4oDIsgcSjTPWU8OrFT4ucmTS3kReIXW/5kJqfv40qb9 xyeMOwAi0VPxxI1JIOwi7Jgd4lRg/ea3FA9zAKWBRaq7OGU9Z2XE2bNV1w9ioUJ8EPjS LnFHC7DfJZEHKnqFtNE9Eums73STQxrXVtcIpcp29OiJ00+qnz6Iz9jwvdfalbrNYAQy I0cVz3GEF4ShMQotS8QeOfzbPZFTAKlSyZTaKivKvavms7EUGn6exoisD1e9U4Jsxc9i 373Q== X-Forwarded-Encrypted: i=1; AJvYcCUUv6BnYzIAR6+eQ9nqMU3b6Zj9lPSrRVNo0Uy0PNQhZtHjdTBtau1f4YbdiEEfDWZxET3IPnWxOUYD1xJCqnYlN30= X-Gm-Message-State: AOJu0YxRqUuFFP+ILl67p1JmahHTW2JifK1O6cFr+rO52yIY9rCdW9MO XY+0jEuMSGApgwAtCzOL1gdPe0H78VJlEzl3SFjid4sufOEcTAYT X-Google-Smtp-Source: AGHT+IE1uwI/qWr+/pX0dMTFpEHgPo3UrJhYENMPGU5Mlv/RiVcvanRBXjjH3iHMZHyWt+ejM7b0jQ== X-Received: by 2002:a5d:6385:0:b0:371:8698:3740 with SMTP id ffacd0b85a97d-371946a5801mr177866f8f.39.1723747683577; Thu, 15 Aug 2024 11:48:03 -0700 (PDT) Received: from ?IPV6:2a02:6b6f:e750:7600:c5:51ce:2b5:970b? ([2a02:6b6f:e750:7600:c5:51ce:2b5:970b]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-429ed648f3fsm2246935e9.6.2024.08.15.11.48.02 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 15 Aug 2024 11:48:03 -0700 (PDT) Message-ID: <0d87c81b-6bf3-4e46-a2d1-a2f9f3a551dd@gmail.com> Date: Thu, 15 Aug 2024 19:48:02 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH mm-unstable v1 2/3] mm/cma: add cma_alloc_folio() To: Yu Zhao , Kefeng Wang Cc: Andrew Morton , Muchun Song , "Matthew Wilcox (Oracle)" , Zi Yan , linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <20240811212129.3074314-1-yuzhao@google.com> <20240811212129.3074314-3-yuzhao@google.com> <6d19d790-92d2-40f9-9797-cc08bf3921fe@huawei.com> Content-Language: en-US From: Usama Arif In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspamd-Server: rspam03 X-Rspam-User: X-Rspamd-Queue-Id: 84CA71A001B X-Stat-Signature: dafoga3pi9t7667u444yrxrqeesbpuoo X-HE-Tag: 1723747685-644502 X-HE-Meta: U2FsdGVkX199sy1Z25OjsBckw07IjTpY96p4FQghjyTTVZTwrHzC+NMYv8F7EjYHaTNfUzRrkgrvYqN3alSKXV2gRiV0xMyTpDy2Z8bnusQoVYqyb5QbbMOinjvOM7XrYUew+jpmZV+ATAk2oayhgQVn8DA7arVAUY9g/ccRm5p50SzBtwywYhtz0qABNEMDjwhn4Ola9E3pFYyREoBlHxzvj+drCsBUjvTUTG3gmwf74VHnj95q+rgqSimTDyBwWKnNhMhefEXgrlyXa6vWRXRcwZgIGAHewenmaBmZ6NIQUH/x2cCd0UJsDRT9Uw7WwJ7HkUSppxgDEzkAolI0gZFZHeS2Uiq6xHeG4Hjdx82fiUaDD965d6nisw4/trds7AFSDx0sEGq5DZDbZ2+2da1Jeo/nOtUrGUsgqcwd8HEqszatH6YRHEuvNtERFZ16mf+XSO4d150whd9TYgpalZBgPwxSPfZlWe8Fu0D/mF47HZnzmSGXGqQRRBM+APyTK9U0tJANnkc4ZRHL4TxzVeadUkKkchE2TzlLt9hnYf7Iv/mPJsHdB3SQBYvZheayKE6xPexx3QVz/PD2fKosBZbj+zA0rbc3GE1CWy2bKq14y9vXM0yBAiao1Vhw4oAkZAUQ4JbEHAZmIGcY2fiwAyo/nS718ib1JVsmx/wubNDZz6AhjQRIlNj41JI0SoJ76JU+SNCUU6EHeHoPPbk3lnEYZbENSJlsWX5raLYKxSEzHVXI3O6pNDPTgSjW+FM3/XnPg7WwhSJubxcTCdurIoFq/+JdN7wJuKRsXalhmVuvH3eFJWPM02aYMqAm4Dxqqizuac50OoLTx7pcQWe+z9AvDaJUaENNp6ko2IofKrxIcr6QKgQZNlAZ/1tT4iqmz0oXgDVRdcnj3ivcAHoOMFdSbj9VLNmLDMQt748DPwfylcMycPhB3h4BYwAmgfSxxlbRq1TBQy+psQNwI1I mxqBQsDD UJ1R7kM/2MGTPf6z8p4mHFRyB0RPMG9zojtMTE/kV3/KJ13IEOPifE1FZJcP7HG9ewRoFDihtepqc/GZDcli1mgauwdylLWswCoDWXfyGaeRkVc4Xnk5Z/D4WqyLRojC16/QVQJ30TmH+qVj2wMxTuZEgegzRh7n1MNFlekYKMmzwWeCkWk8hBnv4BRgJos/WNWR9cmqcKDvG6HETzij6sy+jHkm0bJX5/xSV0ovgQs+eTbZyalSyNl2ts8zrEUQMDA37puU70Fv3BOs1daEyo45ORAMdBM1QDYYtEov7Ss0V8+7hxn/KzHURNnA7uRsHcZGRburZBnWEOv38FIK2e9BL3HuwwrlSfsBPZ43iNZnJbvXLyrJ7C9Sid7V2NftwT9OPGYJkrJD37OTLe0vVVJLCuIJSB8WFdUv2l0tptjbteUBSKXURja/RfyBITQUQ5hf32Vn0WFBud6mYeJbPF2kdL9AiAaGeGJdoGg9R6eyvy3x6iXWVVbN+NnL2lsn060Hws52NR40ZwRjK0r5IJjNaQ3pJ36C9LAcHj+EujM8365occw6AEmyQ9tQ1nQEr0z0TAcH6jvqMgrlGnqmltzjW5Y0YjtsWzCMCZJGBqsfus82uPJHvDm25r+C18tNdcAlIO2BRYMAUq3Fv8sPpQun1ShmQkcszvx39 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 15/08/2024 19:25, Yu Zhao wrote: > On Thu, Aug 15, 2024 at 12:04 PM Yu Zhao wrote: >> >> On Thu, Aug 15, 2024 at 8:41 AM Kefeng Wang wrote: >>> >>> >>> >>> On 2024/8/12 5:21, Yu Zhao wrote: >>>> With alloc_contig_range() and free_contig_range() supporting large >>>> folios, CMA can allocate and free large folios too, by >>>> cma_alloc_folio() and cma_release(). >>>> >>>> Signed-off-by: Yu Zhao >>>> --- >>>> include/linux/cma.h | 1 + >>>> mm/cma.c | 47 ++++++++++++++++++++++++++++++--------------- >>>> 2 files changed, 33 insertions(+), 15 deletions(-) >>>> >>>> diff --git a/include/linux/cma.h b/include/linux/cma.h >>>> index 9db877506ea8..086553fbda73 100644 >>>> --- a/include/linux/cma.h >>>> +++ b/include/linux/cma.h >>>> @@ -46,6 +46,7 @@ extern int cma_init_reserved_mem(phys_addr_t base, phys_addr_t size, >>>> struct cma **res_cma); >>>> extern struct page *cma_alloc(struct cma *cma, unsigned long count, unsigned int align, >>>> bool no_warn); >>>> +extern struct folio *cma_alloc_folio(struct cma *cma, int order, gfp_t gfp); >>>> extern bool cma_pages_valid(struct cma *cma, const struct page *pages, unsigned long count); >>>> extern bool cma_release(struct cma *cma, const struct page *pages, unsigned long count); >>>> >>>> diff --git a/mm/cma.c b/mm/cma.c >>>> index 95d6950e177b..46feb06db8e7 100644 >>>> --- a/mm/cma.c >>>> +++ b/mm/cma.c >>>> @@ -403,18 +403,8 @@ static void cma_debug_show_areas(struct cma *cma) >>>> spin_unlock_irq(&cma->lock); >>>> } >>>> >>>> -/** >>>> - * cma_alloc() - allocate pages from contiguous area >>>> - * @cma: Contiguous memory region for which the allocation is performed. >>>> - * @count: Requested number of pages. >>>> - * @align: Requested alignment of pages (in PAGE_SIZE order). >>>> - * @no_warn: Avoid printing message about failed allocation >>>> - * >>>> - * This function allocates part of contiguous memory on specific >>>> - * contiguous memory area. >>>> - */ >>>> -struct page *cma_alloc(struct cma *cma, unsigned long count, >>>> - unsigned int align, bool no_warn) >>>> +static struct page *__cma_alloc(struct cma *cma, unsigned long count, >>>> + unsigned int align, gfp_t gfp) >>>> { >>>> unsigned long mask, offset; >>>> unsigned long pfn = -1; >>>> @@ -463,8 +453,7 @@ struct page *cma_alloc(struct cma *cma, unsigned long count, >>>> >>>> pfn = cma->base_pfn + (bitmap_no << cma->order_per_bit); >>>> mutex_lock(&cma_mutex); >>>> - ret = alloc_contig_range(pfn, pfn + count, MIGRATE_CMA, >>>> - GFP_KERNEL | (no_warn ? __GFP_NOWARN : 0)); >>>> + ret = alloc_contig_range(pfn, pfn + count, MIGRATE_CMA, gfp); >>>> mutex_unlock(&cma_mutex); >>>> if (ret == 0) { >>>> page = pfn_to_page(pfn); >>>> @@ -494,7 +483,7 @@ struct page *cma_alloc(struct cma *cma, unsigned long count, >>>> page_kasan_tag_reset(nth_page(page, i)); >>>> } >>>> >>>> - if (ret && !no_warn) { >>>> + if (ret && !(gfp & __GFP_NOWARN)) { >>>> pr_err_ratelimited("%s: %s: alloc failed, req-size: %lu pages, ret: %d\n", >>>> __func__, cma->name, count, ret); >>>> cma_debug_show_areas(cma); >>>> @@ -513,6 +502,34 @@ struct page *cma_alloc(struct cma *cma, unsigned long count, >>>> return page; >>>> } >>>> >>>> +/** >>>> + * cma_alloc() - allocate pages from contiguous area >>>> + * @cma: Contiguous memory region for which the allocation is performed. >>>> + * @count: Requested number of pages. >>>> + * @align: Requested alignment of pages (in PAGE_SIZE order). >>>> + * @no_warn: Avoid printing message about failed allocation >>>> + * >>>> + * This function allocates part of contiguous memory on specific >>>> + * contiguous memory area. >>>> + */ >>>> +struct page *cma_alloc(struct cma *cma, unsigned long count, >>>> + unsigned int align, bool no_warn) >>>> +{ >>>> + return __cma_alloc(cma, count, align, GFP_KERNEL | (no_warn ? __GFP_NOWARN : 0)); >>>> +} >>>> + >>>> +struct folio *cma_alloc_folio(struct cma *cma, int order, gfp_t gfp) >>>> +{ >>>> + struct page *page; >>>> + >>>> + if (WARN_ON(order && !(gfp | __GFP_COMP))) >>>> + return NULL; >>>> + >>>> + page = __cma_alloc(cma, 1 << order, order, gfp); >>>> + >>>> + return page ? page_folio(page) : NULL; >>> >>> We don't set large_rmappable for cma alloc folio, which is not consistent >>> with other folio allocation, eg folio_alloc/folio_alloc_mpol(), >>> there is no issue for HugeTLB folio, and for HugeTLB folio must without >>> large_rmappable, but once we use it for mTHP/THP, it need some extra >>> handle, maybe we set large_rmappable here, and clear it in >>> init_new_hugetlb_folio()? >> >> I want to hear what Matthew thinks about this. >> >> My opinion is that we don't want to couple largely rmappable (or >> deferred splittable) with __GFP_COMP, and for that matter, with large >> folios, because the former are specific to THPs whereas the latter can >> potentially work for most types of high order allocations. >> >> Again, IMO, if we want to seriously answer the question of >> Can we get rid of non-compound multi-page allocations? [1] >> then we should start planning on decouple large rmappable from the >> generic folio allocation API. >> >> [1] https://lpc.events/event/18/sessions/184/#20240920 > > Also along the similar lines, Usama is trying to add > PG_partially_mapped [1], which I have explicitly asked him not to > introduce that flag to hugeTLB, unless there are good reasons (none > ATM). > > [1] https://lore.kernel.org/CAOUHufbmgwZwzUuHVvEDMqPGcsxE2hEreRZ4PhK5yz27GdK-Tw@mail.gmail.com/ PG_partially_mapped won't be cleared for hugeTLB in the next revision of the series as suggested by Yu. Its not there in the fix patch I posted as well in https://lore.kernel.org/all/4acdf2b7-ed65-4087-9806-8f4a187b4eb5@gmail.com/