Why did not the kernel use the memory block named by "Node 0 DMA" while the argument of funtion kzalloc is "GFP_KERNEL"?

[孙世龙 sunshilong]

As per the documentation
(https://elixir.bootlin.com/linux/latest/source/include/linux/gfp.h#L292),
which says:
#define GFP_KERNEL (__GFP_RECLAIM | __GFP_IO | __GFP_FS).
It does not explicitly bind the option of GFP_KERNEL to any of the
physical address zone modifiers(i.e. __GFP_DMA,__GFP_HIGHMEM,
__GFP_DMA32,__GFP_MOVABLE,GFP_ZONEMASK) indeed.

And there are free blocks in "Node 0 DMA" indeed.
For your convenience, the most related log is seen below:
Node 0 DMA: 3*4kB (U) 3*8kB (U) 1*16kB (U) 1*32kB (U) 3*64kB(U) 0*128kB
1*256kB (U) 0*512kB 1*1024kB (U) 1*2048kB (M) 3*4096kB (M) = 15892kB
Node 0 DMA32: 14912*4kB (UME) 13850*8kB (UME) 9325*16kB (UME)
5961*32kB(UME) 3622*64kB (UME) 2359*128kB (UME) 1128*256kB (UME)
524*512kB (M) 194*1024kB (UM) 0*2048kB 0*4096kB = 1799872kB
[22041.388033] Node 0 Normal: 1643*4kB (UME) 71*8kB (UME) 47*16kB (UM)
35*32kB (M) 38*64kB (M) 1*128kB (M) 0*256kB 0*512kB 0*1024kB 0*2048kB
0*4096kB = 11572kB

Here is the implementation of the function kzalloc(refer to
https://elixir.bootlin.com/linux/latest/source/include/linux/slab.h#L667):
/**
 * kzalloc - allocate memory. The memory is set to zero.
 * @size: how many bytes of memory are required.
 * @flags: the type of memory to allocate (see kmalloc).
 */
static inline void *kzalloc(size_t size, gfp_t flags)
{
return kmalloc(size, flags | __GFP_ZERO);
}
So I wonder why the kernel did not use the memory block named by
"Node 0 DMA" while the argument of function kzalloc is "GFP_KERNEL".
I heard a saying is that the Linux kernel "will" search the "normal zone"
first, then the "DMA32 zone", and "DMA zone" while there is no "physical
address zone modifier" is explicitly declared.
I have googled it for a long time. But I still could not understand why the
kernel still complains. I would be grateful to have some help with it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20200619/3fd8e41d/attachment.html>