From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: ** X-Spam-Status: No, score=2.7 required=3.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 23AD2C433E0 for ; Fri, 19 Jun 2020 10:00:45 +0000 (UTC) Received: from shelob.surriel.com (shelob.surriel.com [96.67.55.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id E1F4220739 for ; Fri, 19 Jun 2020 10:00:44 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="gJ6HoXea" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E1F4220739 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kernelnewbies-bounces@kernelnewbies.org Received: from localhost ([::1] helo=shelob.surriel.com) by shelob.surriel.com with esmtp (Exim 4.94) (envelope-from ) id 1jmDoY-0007y5-MO; Fri, 19 Jun 2020 06:00:02 -0400 Received: from mail-qt1-x829.google.com ([2607:f8b0:4864:20::829]) by shelob.surriel.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94) (envelope-from ) id 1jmDoW-0007xi-Fd for Kernelnewbies@kernelnewbies.org; Fri, 19 Jun 2020 06:00:00 -0400 Received: by mail-qt1-x829.google.com with SMTP id c12so6689272qtq.11 for ; Fri, 19 Jun 2020 02:59:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=ARqlxoBZY5qLrGWFZNFFdInkmrLx5ZQ6F9XIqM3fKXo=; b=gJ6HoXeaENMuRFHk13C70+KSZbdZk4+Mn+cnY/77R7P9XfgSB5FxYbUWuLgP2MGQei GxREug8c8yiLiGBoW4JHEpqOMsd8JAAQ/jmZZVXt8Q5QCZ6O2jsJUQ+cV1l17G8Vh2J9 bKlT81eSeSCMJeh5UFr7IIeH0SUtzj/HnrKStzhR0524gMNu+6btaEbEVY+0gEYA4ZzT tDXOgfzARdJ8xd3FoBERFVncQr9VTMBMrsP+6wMXXnitpKv64cYRzW7QhR1hdTPZ1LI7 krYywY/UoV9naQESvHMfQ/6wryLG72aeHjnA3Lcvq2gFoV+j2OmqjdOIUAQCT/QFFeZQ 5l6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=ARqlxoBZY5qLrGWFZNFFdInkmrLx5ZQ6F9XIqM3fKXo=; b=iJ+kUn39Fy6xcYC96WB+AiJVE9mYgSj39IgPCTHK51UPVQhaLqEj77bKOb0RYHYl4K QM6n6RmUhhAlG4X4wP36a93eXxBXV8CowKRdwQr47n5K85NB/GF50ysXVjbTgS5Ehiet uHAvDyWqvuI0plLUk7sKzb/bYBk5MK54D4AigBY9sCruRPpGSfL3jObIlIB0r3j3QkKd DxZo16DBp43zKro+RWEO6gPmGrrUT7Q6XrWXtUD1bgs2xXtgFggszPdsbaxWZXiA3U21 iXv6q5mMZwY4eewIOM5dBZn+lo8kcgjQ8tS2iE641sKsvNfX+bWuR+uypUsydwaa8N2I htpg== X-Gm-Message-State: AOAM532GCauy8mzi1k126s9D4KqKOxWVeKubEEQkv1USXXcMs8dzTAuZ G78mNDl1OOl6lVHeA0kSXPjcy7yG8HMbxTnLyJmufBiNy3hB8w== X-Google-Smtp-Source: ABdhPJwianJ3LLTGGfNH0xLKM2wx9GsBsEZBdCpdd+sZ4/MS1LIMAeX4NdWpbkII5CTY2/o1tAE4JtUHewppl8o4z8c= X-Received: by 2002:ac8:3438:: with SMTP id u53mr2467170qtb.8.1592560738993; Fri, 19 Jun 2020 02:58:58 -0700 (PDT) MIME-Version: 1.0 From: =?UTF-8?B?5a2Z5LiW6b6ZIHN1bnNoaWxvbmc=?= Date: Fri, 19 Jun 2020 17:58:48 +0800 Message-ID: Subject: Why did not the kernel use the memory block named by "Node 0 DMA" while the argument of funtion kzalloc is "GFP_KERNEL"? To: Kernelnewbies@kernelnewbies.org X-BeenThere: kernelnewbies@kernelnewbies.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Learn about the Linux kernel List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============6157801046610327915==" Errors-To: kernelnewbies-bounces@kernelnewbies.org --===============6157801046610327915== Content-Type: multipart/alternative; boundary="000000000000218a7d05a86cf105" --000000000000218a7d05a86cf105 Content-Type: text/plain; charset="UTF-8" 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. --000000000000218a7d05a86cf105 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
As per the documentation
(https://elixir.bootl= in.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&= quot; 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) =3D 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 =3D 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 =3D 11572kB = =C2=A0

Here is the implementation of the function kzalloc(refer to <= br>https://elixir.bootlin.com/linux/latest/source/include/linux/s= lab.h#L667):
/**
=C2=A0* kzalloc - allocate memory. The memory is= set to zero.
=C2=A0* @size: how many bytes of memory are required.
= =C2=A0* @flags: the type of memory to allocate (see kmalloc).
=C2=A0*/static inline void *kzalloc(size_t size, gfp_t flags)
{
return kma= lloc(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"
f= irst, then the "DMA32 zone", and "DMA zone" while there= is no "physical
address zone modifier" is explicitly declare= d.
I have googled it for a long time. But I still could not understand = why the=C2=A0
kernel still complains. I would be grateful to have some = help with it.
--000000000000218a7d05a86cf105-- --===============6157801046610327915== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies --===============6157801046610327915==--