On Tue, Jul 10, 2018 at 6:24 PM Wei Wang <wei.w.wang@xxxxxxxxx> wrote:
>
> We only get addresses of the "MAX_ORDER-1" blocks into the array. The
> max size of the array that could be allocated by kmalloc is
> KMALLOC_MAX_SIZE (i.e. 4MB on x86). With that max array, we could load
> "4MB / sizeof(u64)" addresses of "MAX_ORDER-1" blocks, that is, 2TB free
> memory at most. We thought about removing that 2TB limitation by passing
> in multiple such max arrays (a list of them).
No.
Stop this already./
You're doing everthing wrong.
If the array has to describe *all* memory you will ever free, then you
have already lost.
Just do it in chunks.
I don't want the VM code to even fill in that big of an array anyway -
this all happens under the zone lock, and you're walking a list that
is bad for caching anyway.
So plan on an interface that allows _incremental_ freeing, because any
plan that starts with "I worry that maybe two TERABYTES of memory
isn't big enough" is so broken that it's laughable.
That was what I tried to encourage with actually removing the pages
form the page list. That would be an _incremental_ interface. You can
remove MAX_ORDER-1 pages one by one (or a hundred at a time), and mark
them free for ballooning that way. And if you still feel you have tons
of free memory, just continue removing more pages from the free list.
Notice? Incremental. Not "I want to have a crazy array that is enough
to hold 2TB at one time".
So here's the rule:
- make it a simple array interface
- make the array *small*. Not megabytes. Kilobytes. Because if you're
filling in megabytes worth of free pointers while holding the zone
lock, you're doing something wrong.
- design the interface so that you do not *need* to have this crazy
"all or nothing" approach.
See what I'm trying to push for. Think "low latency". Think "small
arrays". Think "simple and straightforward interfaces".
At no point should you ever worry about "2TB". Never.
Linus
