From: Christoph Hellwig <hch@infradead.org>
To: David Hildenbrand <david@redhat.com>
Cc: Chris Goldsworthy <cgoldswo@codeaurora.org>,
akpm@linux-foundation.org, linux-mm@kvack.org,
linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org,
pratikp@codeaurora.org, pdaly@codeaurora.org,
sudraja@codeaurora.org, iamjoonsoo.kim@lge.com,
linux-arm-msm-owner@vger.kernel.org,
Vinayak Menon <vinmenon@codeaurora.org>,
linux-kernel-owner@vger.kernel.org
Subject: Re: [PATCH v2] mm: cma: indefinitely retry allocations in cma_alloc
Date: Mon, 28 Sep 2020 08:39:07 +0100 [thread overview]
Message-ID: <20200928073907.GA29322@infradead.org> (raw)
In-Reply-To: <a3d62a77-4c4f-e86c-de6d-5222c2a747e0@redhat.com>
On Tue, Sep 15, 2020 at 09:53:30AM +0200, David Hildenbrand wrote:
> Two thoughts:
>
> 1. Most (all?) alloc_contig_range() users are interested in handling
> short-term pinnings in a nice way (IOW, make the allocation succeed).
> I'd much rather want to see this being handled in a nice fashion inside
> alloc_contig_range() than having to encode endless loops in the caller.
> This means I strongly prefer something like [3] if feasible. But I can
> understand that stuff ([5]) is complicated. I have to admit that I am
> not an expert on the short term pinning described by you, and how to
> eventually fix it.
Agreed. Also retrying forever is simply broken, and will lead to
deadlocks for the DMA calls into CMA, so with my dma-mapping hat on
I have to hard-NAK this approach.
next prev parent reply other threads:[~2020-09-28 7:39 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <06489716814387e7f147cf53d1b185a8@codeaurora.org>
2020-09-11 19:17 ` [PATCH v2] cma_alloc(), indefinitely retry allocations for -EBUSY failures Chris Goldsworthy
2020-09-11 19:17 ` Chris Goldsworthy
[not found] ` <1599851809-4342-1-git-send-email-cgoldswo@codeaurora.org>
2020-09-11 19:17 ` [PATCH v2] mm: cma: indefinitely retry allocations in cma_alloc Chris Goldsworthy
2020-09-11 19:17 ` Chris Goldsworthy
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 [this message]
[not found] <1599855850-11337-1-git-send-email-cgoldswo@codeaurora.org>
2020-09-11 20:24 ` Chris Goldsworthy
[not found] <1599857630-23714-1-git-send-email-cgoldswo@codeaurora.org>
2020-09-11 20:54 ` Chris Goldsworthy
2020-09-11 21:37 ` Florian Fainelli
2020-09-11 21:42 ` Randy Dunlap
2020-09-14 18:45 ` Chris Goldsworthy
2020-09-14 18:39 ` Chris Goldsworthy
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=20200928073907.GA29322@infradead.org \
--to=hch@infradead.org \
--cc=akpm@linux-foundation.org \
--cc=cgoldswo@codeaurora.org \
--cc=david@redhat.com \
--cc=iamjoonsoo.kim@lge.com \
--cc=linux-arm-msm-owner@vger.kernel.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel-owner@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=pdaly@codeaurora.org \
--cc=pratikp@codeaurora.org \
--cc=sudraja@codeaurora.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 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.