[Devel] [PATCH VZ9] dm-qcow2-map: disable high-order allocation warning
Pavel Tikhomirov
ptikhomirov at virtuozzo.com
Mon Nov 11 13:00:17 MSK 2024
On 11/11/24 17:44, Alexey Kuznetsov wrote:
> [You don't often get email from alexey.n.kuznetsov at gmail.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
>
> Hmm.
>
> What are chances to get 4M with GFP_NOIO? I do not even need
> to guess, I know - 0.
>
> Damn, this is not a legal code. Leave warn in place, it must complain.
>
> If we cannot redo this using normal sized buffers, make a pool, make
> a queue to wait for pool, or use kvmalloc, or whatever. But only not this.
As you can see in my comment in v2 of this patch:
> [PATCH v2 VZ9] dm-qcow2-map: disable high-order allocation warning
> Note: According to Documentation/core-api/gfp_mask-from-fs-io.rst
> GFP_NOIO is not supported in vmalloc, so probably we don't have an
> option to switch to kvmalloc here.
kvmalloc will not likely work.
I agree about 4M will likely cause problem after memory overcommit /
long uptime with high memory fragmentation.
I will think if we can redo this with normal sized buffers.
As of pool and queue to wait for pool, let me reword it to check if I
understand you correctly:
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?
>
>
>
>
>
>
>
>
> On Mon, Nov 11, 2024 at 3:41 PM Pavel Tikhomirov
> <ptikhomirov at virtuozzo.com> wrote:
>>
>> Disable the warning:
>>
>> kernel: order 10 >= 10, gfp 0x40c00
>> kernel: WARNING: CPU: 5 PID: 182 at mm/page_alloc.c:5630 __alloc_pages+0x1d7/0x3f0
>> kernel: process_compressed_read+0x6f/0x590 [dm_qcow2]
>>
>> As with 1M clusters and in case of zstd compression the buffer size
>> (clu_size + sizeof(ZSTD_DCtx) + ZSTD_BLOCKSIZE_MAX + clu_size +
>> ZSTD_BLOCKSIZE_MAX + 64 = 2520776) can only fit into 4M (10-th order)
>> allocation.
>>
>> https://virtuozzo.atlassian.net/browse/VSTOR-94596
>> Signed-off-by: Pavel Tikhomirov <ptikhomirov at virtuozzo.com>
>>
>> Feature: dm-qcow2: ZSTD decompression
>> ---
>> drivers/md/dm-qcow2-map.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/md/dm-qcow2-map.c b/drivers/md/dm-qcow2-map.c
>> index 6585f3fac6e7b..18f9442493831 100644
>> --- a/drivers/md/dm-qcow2-map.c
>> +++ b/drivers/md/dm-qcow2-map.c
>> @@ -3671,7 +3671,7 @@ static void process_compressed_read(struct qcow2 *qcow2, struct list_head *read_
>> dctxlen = zlib_inflate_workspacesize();
>>
>>
>> - buf = kmalloc(qcow2->clu_size + dctxlen, GFP_NOIO);
>> + buf = kmalloc(qcow2->clu_size + dctxlen, GFP_NOIO | __GFP_ORDER_NOWARN);
>> if (!buf) {
>> end_qios(read_list, BLK_STS_RESOURCE);
>> return;
>> --
>> 2.47.0
>>
>> _______________________________________________
>> Devel mailing list
>> Devel at openvz.org
>> https://lists.openvz.org/mailman/listinfo/devel
--
Best regards, Tikhomirov Pavel
Senior Software Developer, Virtuozzo.
More information about the Devel
mailing list