From: Mike Kravetz <mike.kravetz@oracle.com>
To: Roman Gushchin <guro@fb.com>, Andrew Morton <akpm@linux-foundation.org>
Cc: Zi Yan <ziy@nvidia.com>, Joonsoo Kim <iamjoonsoo.kim@lge.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
kernel-team@fb.com
Subject: Re: [PATCH rfc 0/2] mm: cma: make cma_release() non-blocking
Date: Wed, 21 Oct 2020 17:15:53 -0700 [thread overview]
Message-ID: <3f455d27-6d99-972f-b77f-b5b473b7614d@oracle.com> (raw)
In-Reply-To: <20201016225254.3853109-1-guro@fb.com>
On 10/16/20 3:52 PM, Roman Gushchin wrote:
> This small patchset makes cma_release() non-blocking and simplifies
> the code in hugetlbfs, where previously we had to temporarily drop
> hugetlb_lock around the cma_release() call.
>
> It should help Zi Yan on his work on 1 GB THPs: splitting a gigantic
> THP under a memory pressure requires a cma_release() call. If it's
> a blocking function, it complicates the already complicated code.
> Because there are at least two use cases like this (hugetlbfs is
> another example), I believe it's just better to make cma_release()
> non-blocking.
>
> It also makes it more consistent with other memory releasing functions
> in the kernel: most of them are non-blocking.
Thanks for looking into this Roman.
I may be missing something, but why does cma_release have to be blocking
today? Certainly, it takes the bitmap in cma_clear_bitmap and could
block. However, I do not see why cma->lock has to be a mutex. I may be
missing something, but I do not see any code protected by the mutex doing
anything that could sleep?
Could we simply change that mutex to a spinlock?
--
Mike Kravetz
next prev parent reply other threads:[~2020-10-22 0:16 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-16 22:52 [PATCH rfc 0/2] mm: cma: make cma_release() non-blocking Roman Gushchin
2020-10-16 22:52 ` [PATCH rfc 1/2] " Roman Gushchin
2020-10-16 22:52 ` [PATCH rfc 2/2] mm: hugetlb: don't drop hugetlb_lock around cma_release() call Roman Gushchin
2020-10-22 0:15 ` Mike Kravetz [this message]
2020-10-22 2:33 ` [PATCH rfc 0/2] mm: cma: make cma_release() non-blocking Roman Gushchin
2020-10-22 16:42 ` Mike Kravetz
2020-10-22 17:16 ` Roman Gushchin
2020-10-22 17:25 ` Mike Kravetz
2020-10-22 1:54 ` Xiaqing (A)
2020-10-22 2:45 ` Roman Gushchin
2020-10-22 3:47 ` Xiaqing (A)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3f455d27-6d99-972f-b77f-b5b473b7614d@oracle.com \
--to=mike.kravetz@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=guro@fb.com \
--cc=iamjoonsoo.kim@lge.com \
--cc=kernel-team@fb.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ziy@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.