From: Florian Fainelli <f.fainelli@gmail.com>
To: Chris Goldsworthy <cgoldswo@codeaurora.org>,
linux-kernel@vger.kernel.org
Cc: Vinayak Menon <vinmenon@codeaurora.org>
Subject: Re: [PATCH v2] mm: cma: indefinitely retry allocations in cma_alloc
Date: Fri, 11 Sep 2020 14:37:28 -0700 [thread overview]
Message-ID: <410a4e0c-f924-4564-ae1e-cc9f6292c88e@gmail.com> (raw)
In-Reply-To: <010101747ef2b8fc-a5e44a5a-dcf4-4828-a1d4-a099df63f2df-000000@us-west-2.amazonses.com>
On 9/11/2020 1:54 PM, Chris Goldsworthy wrote:
> CMA allocations will fail if 'pinned' pages are in a CMA area, since we
> cannot migrate pinned pages. The _refcount of a struct page being greater
> than _mapcount for that page can cause pinning for anonymous pages. This
> is because try_to_unmap(), which (1) is called in the CMA allocation path,
> and (2) decrements both _refcount and _mapcount for a page, will stop
> unmapping a page from VMAs once the _mapcount for a page reaches 0. This
> implies that after try_to_unmap() has finished successfully for a page
> where _recount > _mapcount, that _refcount will be greater than 0. Later
> in the CMA allocation path in migrate_page_move_mapping(), we will have one
> more reference count than intended for anonymous pages, meaning the
> allocation will fail for that page.
>
> One example of where _refcount can be greater than _mapcount for a page we
> would not expect to be pinned is inside of copy_one_pte(), which is called
> during a fork. For ptes for which pte_present(pte) == true, copy_one_pte()
> will increment the _refcount field followed by the _mapcount field of a
> page. If the process doing copy_one_pte() is context switched out after
> incrementing _refcount but before incrementing _mapcount, then the page
> will be temporarily pinned.
>
> So, inside of cma_alloc(), instead of giving up when alloc_contig_range()
> returns -EBUSY after having scanned a whole CMA-region bitmap, perform
> retries indefinitely, with sleeps, to give the system an opportunity to
> unpin any pinned pages.
I am by no means an authoritative CMA person but this behavior does not
seem acceptable, there is no doubt the existing one is sub-optimal under
specific circumstances, but an indefinite retry, as well as a 100ms
sleep appear to be arbitrary at best. How about you introduce a
parameter that allows the tuning of the number of retries and/or delay
between retries?
>
> Signed-off-by: Chris Goldsworthy <cgoldswo@codeaurora.org>
> Co-developed-by: Vinayak Menon <vinmenon@codeaurora.org>
> Signed-off-by: Vinayak Menon <vinmenon@codeaurora.org>
> ---
> mm/cma.c | 25 +++++++++++++++++++++++--
> 1 file changed, 23 insertions(+), 2 deletions(-)
>
> diff --git a/mm/cma.c b/mm/cma.c
> index 7f415d7..90bb505 100644
> --- a/mm/cma.c
> +++ b/mm/cma.c
> @@ -32,6 +32,7 @@
> #include <linux/highmem.h>
> #include <linux/io.h>
> #include <linux/kmemleak.h>
> +#include <linux/delay.h>
> #include <trace/events/cma.h>
>
> #include "cma.h"
> @@ -442,8 +443,28 @@ struct page *cma_alloc(struct cma *cma, size_t count, unsigned int align,
> bitmap_maxno, start, bitmap_count, mask,
> offset);
> if (bitmap_no >= bitmap_maxno) {
> - mutex_unlock(&cma->lock);
> - break;
> + if (ret == -EBUSY) {
> + mutex_unlock(&cma->lock);
> +
> + /*
> + * Page may be momentarily pinned by some other
> + * process which has been scheduled out, e.g.
> + * in exit path, during unmap call, or process
> + * fork and so cannot be freed there. Sleep
> + * for 100ms and retry the allocation.
> + */
> + start = 0;
> + ret = -ENOMEM;
> + msleep(100);
> + continue;
> + } else {
> + /*
> + * ret == -ENOMEM - all bits in cma->bitmap are
> + * set, so we break accordingly.
> + */
> + mutex_unlock(&cma->lock);
> + break;
> + }
> }
> bitmap_set(cma->bitmap, bitmap_no, bitmap_count);
> /*
>
--
Florian
next prev parent reply other threads:[~2020-09-11 21:37 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1599857630-23714-1-git-send-email-cgoldswo@codeaurora.org>
2020-09-11 20:54 ` [PATCH v2] mm: cma: indefinitely retry allocations in cma_alloc Chris Goldsworthy
2020-09-11 21:37 ` Florian Fainelli [this message]
2020-09-11 21:42 ` Randy Dunlap
2020-09-14 18:45 ` Chris Goldsworthy
2020-09-14 18:39 ` Chris Goldsworthy
[not found] <1599855850-11337-1-git-send-email-cgoldswo@codeaurora.org>
2020-09-11 20:24 ` Chris Goldsworthy
[not found] <06489716814387e7f147cf53d1b185a8@codeaurora.org>
[not found] ` <1599851809-4342-1-git-send-email-cgoldswo@codeaurora.org>
2020-09-11 19:17 ` Chris Goldsworthy
[not found] ` <010101747e998731-e49f209f-8232-4496-a9fc-2465334e70d7-000000@us-west-2.amazonses.com>
2020-09-14 9:31 ` David Hildenbrand
2020-09-14 18:33 ` Chris Goldsworthy
2020-09-14 21:52 ` Chris Goldsworthy
2020-09-15 7:53 ` David Hildenbrand
2020-09-17 17:26 ` Chris Goldsworthy
2020-09-17 17:54 ` Chris Goldsworthy
2020-09-24 5:13 ` Chris Goldsworthy
2020-09-28 7:39 ` Christoph Hellwig
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=410a4e0c-f924-4564-ae1e-cc9f6292c88e@gmail.com \
--to=f.fainelli@gmail.com \
--cc=cgoldswo@codeaurora.org \
--cc=linux-kernel@vger.kernel.org \
--cc=vinmenon@codeaurora.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).