On Mon, Aug 17, 2020 at 05:45:59PM +0200, David Hildenbrand wrote:
On 17.08.20 17:27, Minchan Kim wrote:
quoted
On Sun, Aug 16, 2020 at 02:31:22PM +0200, David Hildenbrand wrote:
quoted
On 14.08.20 19:31, Minchan Kim wrote:
quoted
There is a need for special HW to require bulk allocation of
high-order pages. For example, 4800 * order-4 pages.
To meet the requirement, a option is using CMA area because
page allocator with compaction under memory pressure is
easily failed to meet the requirement and too slow for 4800
times. However, CMA has also the following drawbacks:
* 4800 of order-4 * cma_alloc is too slow
To avoid the slowness, we could try to allocate 300M contiguous
memory once and then split them into order-4 chunks.
The problem of this approach is CMA allocation fails one of the
pages in those range couldn't migrate out, which happens easily
with fs write under memory pressure.
Why not chose a value in between? Like try to allocate MAX_ORDER - 1
chunks and split them. That would already heavily reduce the call frequency.
I think you meant this:
alloc_pages(GFP_KERNEL|__GFP_NOWARN, MAX_ORDER - 1)
It would work if system has lots of non-fragmented free memory.
However, once they are fragmented, it doesn't work. That's why we have
seen even order-4 allocation failure in the field easily and that's why
CMA was there.
CMA has more logics to isolate the memory during allocation/freeing as
well as fragmentation avoidance so that it has less chance to be stealed
from others and increase high success ratio. That's why I want this API
to be used with CMA or movable zone.
I was talking about doing MAX_ORDER - 1 CMA allocations instead of one
big 300M allocation. As you correctly note, memory placed into CMA
should be movable, except for (short/long) term pinnings. In these
cases, doing allocations smaller than 300M and splitting them up should
be good enough to reduce the call frequency, no?
I should have written that. The 300M I mentioned is really minimum size.
In some scenraio, we need way bigger than 300M, up to several GB.
Furthermore, the demand would be increased in near future.
quoted
A usecase is device can set a exclusive CMA area up when system boots.
When device needs 4800 * order-4 pages, it could call this bulk against
of the area so that it could effectively be guaranteed to allocate
enough fast.
Just wondering
a) Why does it have to be fast?
That's because it's related to application latency, which ends up
user feel bad.
b) Why does it need that many order-4 pages?
It's HW requirement. I couldn't say much about that.
c) How dynamic is the device need at runtime?
Whenever the application launched. It depends on user's usage pattern.
d) Would it be reasonable in your setup to mark a CMA region in a way
such that it will never be used for other (movable) allocations,
I don't get your point. If we don't want the area to used up for
other movable allocation, why should we use it as CMA first?
It sounds like reserved memory and just wasted the memory.
Please clarify if I misudersoold your suggestion.
guaranteeing that you can immediately allocate it? Something like,
reserving a region during boot you know you'll immediately need later
completely for a device?
--
Thanks,
David / dhildenb