[Devel] [PATCH VZ9] dm-qcow2-map: disable high-order allocation warning
Alexey Kuznetsov
alexey.n.kuznetsov at gmail.com
Mon Nov 11 15:50:54 MSK 2024
On Mon, Nov 11, 2024 at 6:00 PM Pavel Tikhomirov
<ptikhomirov at virtuozzo.com> wrote:
> kvmalloc will not likely work.
In any case, use of kvmalloc in data path would be a bug as well,
it is to slow to be taken seriously.
> I agree about 4M will likely cause problem after memory overcommkeit /
> long uptime with high memory fragmentation.
No special load is needed.
With GFP_NOIO it is possible to allocate such gfp only at boot time or
if machine is virgin idle
and was cleaned up with drop_caches. BTW I am dealing with 2M pages right now
and has come to conclusion without pool it is hopeless.
> We can pre-allocate some amount of memory for handling those dm-qcow2
> compressed reads and get memory from it with 4M chunks, but then if we
> have too many requests even if free memory is available we would end up
> waiting to get memory from this pool until some other thread releases
> their buffer. Likely you talk about gen_pool_create, correct?
Nah, it is the first time I hear about gen_pool_create. :-) Trying to figure
out what is this.
I mean it is rather like ancient mempool.c. Only I would not use it,
the pool structure is too simple to search for it, it is easier to do
from scratch.
Also we can refill it in filler thread, with GFP_KERNEL, and shrink to some min
size, when devices are idle. If pool is never shunk to zero, this GFP_KERNEL
will not cause deadlocks.
More information about the Devel
mailing list