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 ins
On 2020-09-17 10:54, Chris Goldsworthy wrote:
On 2020-09-15 00:53, David Hildenbrand wrote:
On 14.09.20 20:33, Chris Goldsworthy wrote:
On 2020-09-14 02:31, David Hildenbrand wrote:
On 11.09.20 21:17, Chris Goldsworthy wrote:
So, inside of cma_alloc(), instead of giving up when
alloc_contig_
On 2020-09-15 00:53, David Hildenbrand wrote:
On 14.09.20 20:33, Chris Goldsworthy wrote:
On 2020-09-14 02:31, David Hildenbrand wrote:
On 11.09.20 21:17, Chris Goldsworthy wrote:
So, inside of cma_alloc(), instead of giving up when
alloc_contig_range()
returns -EBUSY after having scanned a w
On 2020-09-15 00:53, David Hildenbrand wrote:
On 14.09.20 20:33, Chris Goldsworthy wrote:
On 2020-09-14 02:31, David Hildenbrand wrote:
On 11.09.20 21:17, Chris Goldsworthy wrote:
So, inside of cma_alloc(), instead of giving up when
alloc_contig_range()
returns -EBUSY after having scanned a w
On 14.09.20 20:33, Chris Goldsworthy wrote:
> On 2020-09-14 02:31, David Hildenbrand wrote:
>> On 11.09.20 21:17, Chris Goldsworthy wrote:
>>>
>>> So, inside of cma_alloc(), instead of giving up when
>>> alloc_contig_range()
>>> returns -EBUSY after having scanned a whole CMA-region bitmap, perfor
On 2020-09-14 11:33, Chris Goldsworthy wrote:
On 2020-09-14 02:31, David Hildenbrand wrote:
What about long-term pinnings? IIRC, that can happen easily e.g., with
vfio (and I remember there is a way via vmsplice).
Not convinced trying forever is a sane approach in the general case
...
Hi Dav
On 2020-09-11 14:42, Randy Dunlap wrote:
On 9/11/20 2:37 PM, Florian Fainelli wrote:
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
On 2020-09-11 14:37, Florian Fainelli wrote:
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 anonym
On 2020-09-14 02:31, David Hildenbrand wrote:
On 11.09.20 21:17, Chris Goldsworthy wrote:
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 o
On 11.09.20 21:17, 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(),
On 9/11/20 2:37 PM, Florian Fainelli wrote:
>
>
> 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 pinnin
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(),
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
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
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
15 matches
Mail list logo
