Message ID | 20230607090734.1259-1-haifeng.xu@shopee.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:994d:0:b0:3d9:f83d:47d9 with SMTP id k13csp122818vqr; Wed, 7 Jun 2023 02:23:48 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ5eXlJnJDJ1IK75JpYm7h+r9tlE5IrKD9Qg8cCuk+j7QYoD22gp1Q2TUxtIdhYuxGuEJqds X-Received: by 2002:a17:902:a5c5:b0:1b1:9218:6bf3 with SMTP id t5-20020a170902a5c500b001b192186bf3mr2320586plq.37.1686129828439; Wed, 07 Jun 2023 02:23:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1686129828; cv=none; d=google.com; s=arc-20160816; b=LInO8xqd9ojgsAn/1HLOcXKjV/C8Oau1sPWcIjjDgva0RoRJXL8gztJrStZ316V7XT 5RjYxN25ToC55SATqsXYBLOsAOyaUOeVyMFZp6uLbglQN33Y/Iuj7XebwlXZTgKZBfOi PjJHqNk6KPAL306qFzT5xgtv6YKjU+EYvL3B+/8C2miGcjK8/vjIOhSVX21xILTC0KHy sg8YC6vETbXPAGZYNrcOQieVDT97H/5uT9mlH10OaU1DKCYORMqJiS2SrS6LKNOX36L2 ibNzJbYcSLFQ307ntkl9UugRysJvg3Mcyi38P9l0LDPAyxdPfoPnJBxNq5CwB6P5nyzs cs2w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=QnoLhVADhihYKgZNBEzok/V+ENlQGgAVYWmM7AcnihM=; b=zLHtwqNF8iwLHYGJlnO7zzwJuEpLp7KnMUAIvx7y74dGHB0SOIQELycsDUSshWL6+a SVr93PYKkMViHq1PPOb4zdMvL9vC6MX4UXVpiYHGFIZuZGZz8bO+8lEVZ4KyUu/YA3hN v67kxXNx8CYAFGkok9RI+QOp3Z06i1Hwx/SPmW986ZBgwVrP8jSiYMJXJ4awo3JN1gYe M6zhZUF2O0YHoiWpLYc8xwzzwDhu8y8W0EXV8ouvMSGRCvWduweVGVKHbs2IgPbJ+Mii 20byAnyq5BsZyfNRykmcw7rCuCW2oTl0AULD5FE2WjgsmEhCYSWN7r8kaEDPIobuh7R9 u64w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@shopee.com header.s=shopee.com header.b="Sz4/tFdN"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=shopee.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id t16-20020a170902e85000b001ab18790b12si8888219plg.97.2023.06.07.02.23.35; Wed, 07 Jun 2023 02:23:48 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@shopee.com header.s=shopee.com header.b="Sz4/tFdN"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=shopee.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239845AbjFGJI4 (ORCPT <rfc822;literming00@gmail.com> + 99 others); Wed, 7 Jun 2023 05:08:56 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33208 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239212AbjFGJIZ (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 7 Jun 2023 05:08:25 -0400 Received: from mail-oi1-x22d.google.com (mail-oi1-x22d.google.com [IPv6:2607:f8b0:4864:20::22d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 761C01BE3 for <linux-kernel@vger.kernel.org>; Wed, 7 Jun 2023 02:07:47 -0700 (PDT) Received: by mail-oi1-x22d.google.com with SMTP id 5614622812f47-38dec65ab50so6192538b6e.2 for <linux-kernel@vger.kernel.org>; Wed, 07 Jun 2023 02:07:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=shopee.com; s=shopee.com; t=1686128867; x=1688720867; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=QnoLhVADhihYKgZNBEzok/V+ENlQGgAVYWmM7AcnihM=; b=Sz4/tFdNyQ6kCJCvi04tf2Vo5gs9uzqidrUilAUXG/bDicmh6yy4eHQB7r+wSLDlBy GNwFW0YF6SdiOYRQEkFF1DO5r+1iRP9qcllczA2709q74ejFiuaEoAFGZ06Uwo44tqYb q924mcuYUiFeIyzWAFB3HGYBnO+TULO5nkfAAZag/rvaViZEfaOMpuyNfcMA3c4hpKmC ZMKnUKNGFtPd+TYZZjL0mn7fBxfgqiL8b+DE/SHA5twfwgfMVebRFWD/lqNkcisKOyRo axXUimwvrRJbdAgVCYWtHMGm6RDxeHpXuJtIciVM1p+P1Li7CzZziLtofhRHaAd60682 B2fw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686128867; x=1688720867; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=QnoLhVADhihYKgZNBEzok/V+ENlQGgAVYWmM7AcnihM=; b=l7M5yDXvN1RHDavDoCixGsbu3UVuTBnrvKL0ucg56+8qT8zRz86PXTNphdWnW0B7k5 wAqCodDLE5HU2K5MClawABn1BGG+qgIZA1a9KLEWGrzNutA+JVdDn4HVuC0v01GiaTUw NM9J42wPQHMeEY/MzP8y3+TmJ+RbWoSsSoIQc67pvSphTbycuXK3hdj+Qt3e6y2qa/KN Q+4/NRiW01Wc30o2pfcm7fOqgdFg3VZ8WkQFnBj2/FklRqSqB+880cGN4viK4LJSOk48 w5uQJPh9UDoRdypUHYphtv264gh0aF4DisJ6dyjklb7nZErcI5YZUU2SAvH1EoxOFE8i nwdw== X-Gm-Message-State: AC+VfDwzarJy+iusyWuJhcPPJLYgDC5TRU0gyALvg1qEKD93WAxvDEVL aCVo0+j5Em3VsluIdy1SwDDC4Q== X-Received: by 2002:a05:6808:b2f:b0:399:156b:fcc1 with SMTP id t15-20020a0568080b2f00b00399156bfcc1mr4837460oij.32.1686128866811; Wed, 07 Jun 2023 02:07:46 -0700 (PDT) Received: from ubuntu-hf2.default.svc.cluster.local ([101.127.248.173]) by smtp.gmail.com with ESMTPSA id q3-20020a17090311c300b001a69dfd918dsm9967076plh.187.2023.06.07.02.07.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 07 Jun 2023 02:07:46 -0700 (PDT) From: Haifeng Xu <haifeng.xu@shopee.com> To: rppt@kernel.org Cc: mhocko@kernel.org, akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Haifeng Xu <haifeng.xu@shopee.com> Subject: [PATCH] mm/mm_init.c: add debug messsge for dma zone Date: Wed, 7 Jun 2023 09:07:34 +0000 Message-Id: <20230607090734.1259-1-haifeng.xu@shopee.com> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1768035271070894215?= X-GMAIL-MSGID: =?utf-8?q?1768035271070894215?= |
Series |
mm/mm_init.c: add debug messsge for dma zone
|
|
Commit Message
Haifeng Xu
June 7, 2023, 9:07 a.m. UTC
If freesize is less than dma_reserve, print warning message to report
this case.
Signed-off-by: Haifeng Xu <haifeng.xu@shopee.com>
---
mm/mm_init.c | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
Comments
On Wed 07-06-23 09:07:34, Haifeng Xu wrote: > If freesize is less than dma_reserve, print warning message to report > this case. Why? > Signed-off-by: Haifeng Xu <haifeng.xu@shopee.com> > --- > mm/mm_init.c | 11 ++++++++--- > 1 file changed, 8 insertions(+), 3 deletions(-) > > diff --git a/mm/mm_init.c b/mm/mm_init.c > index 232efac9a929..9a9d6a52471c 100644 > --- a/mm/mm_init.c > +++ b/mm/mm_init.c > @@ -1561,9 +1561,14 @@ static void __init free_area_init_core(struct pglist_data *pgdat) > } > > /* Account for reserved pages */ > - if (j == 0 && freesize > dma_reserve) { > - freesize -= dma_reserve; > - pr_debug(" %s zone: %lu pages reserved\n", zone_names[0], dma_reserve); > + if (j == 0) { > + if (freesize >= dma_reserve) { > + freesize -= dma_reserve; > + pr_debug(" %s zone: %lu pages reserved\n", > + zone_names[0], dma_reserve); > + } else > + pr_warn(" %s zone: %lu reserved pages exceeds freesize %lu\n", > + zone_names[0], dma_reserve, freesize); > } > > if (!is_highmem_idx(j)) > -- > 2.25.1
On 07.06.23 12:16, Michal Hocko wrote: > On Wed 07-06-23 09:07:34, Haifeng Xu wrote: >> If freesize is less than dma_reserve, print warning message to report >> this case. > > Why? I'd like to second that question, and add a) Did you run into that scenario? b) What can an admin do in that case with that error messages? If it reveals a buggy situation, maybe a WARN_ON_ONCE() is warranted ... but maybe only if anybody actually ran into that issue.
On 2023/6/7 18:22, David Hildenbrand wrote: > On 07.06.23 12:16, Michal Hocko wrote: >> On Wed 07-06-23 09:07:34, Haifeng Xu wrote: >>> If freesize is less than dma_reserve, print warning message to report >>> this case. >> >> Why? > > I'd like to second that question, and add > > a) Did you run into that scenario? > b) What can an admin do in that case with that error messages? > > If it reveals a buggy situation, maybe a WARN_ON_ONCE() is warranted ... but maybe only if anybody actually ran into that issue. > I didn't run into that scenario, just from code review. I think the account for reserved pages is similar to memmap pages, if freesize is less than memmap pages, it print a warning message, so for dma_reserve, it can also does the same thing.
On 2023/6/7 18:22, David Hildenbrand wrote: > On 07.06.23 12:16, Michal Hocko wrote: >> On Wed 07-06-23 09:07:34, Haifeng Xu wrote: >>> If freesize is less than dma_reserve, print warning message to report >>> this case. >> >> Why? > > I'd like to second that question, and add > > a) Did you run into that scenario? > b) What can an admin do in that case with that error messages? In theory,dma_reserve shouldn't exceed freesize, so the error messages can remind us to verify whether the configuration of reserved memory is correct. > > If it reveals a buggy situation, maybe a WARN_ON_ONCE() is warranted ... but maybe only if anybody actually ran into that issue. >
On Thu 08-06-23 15:38:48, Haifeng Xu wrote: > > > On 2023/6/7 18:22, David Hildenbrand wrote: > > On 07.06.23 12:16, Michal Hocko wrote: > >> On Wed 07-06-23 09:07:34, Haifeng Xu wrote: > >>> If freesize is less than dma_reserve, print warning message to report > >>> this case. > >> > >> Why? > > > > I'd like to second that question, and add > > > > a) Did you run into that scenario? > > b) What can an admin do in that case with that error messages? > > In theory,dma_reserve shouldn't exceed freesize, so the error messages can remind us > to verify whether the configuration of reserved memory is correct. I am not really convinced this is worth touching the code TBH.
On Thu, Jun 08, 2023 at 11:18:02AM +0200, Michal Hocko wrote: > On Thu 08-06-23 15:38:48, Haifeng Xu wrote: > > > > > > On 2023/6/7 18:22, David Hildenbrand wrote: > > > On 07.06.23 12:16, Michal Hocko wrote: > > >> On Wed 07-06-23 09:07:34, Haifeng Xu wrote: > > >>> If freesize is less than dma_reserve, print warning message to report > > >>> this case. > > >> > > >> Why? > > > > > > I'd like to second that question, and add > > > > > > a) Did you run into that scenario? > > > b) What can an admin do in that case with that error messages? > > > > In theory,dma_reserve shouldn't exceed freesize, so the error messages can remind us > > to verify whether the configuration of reserved memory is correct. > > I am not really convinced this is worth touching the code TBH. The only architecture that sets the dma_reserve is x86_64 and it sets it to the number of reserved pages in DMA zone. There is no way freesize will be less than dma_reserve. I'm not sure that in general dma_reserve has some value now, but that's a completely different story. > -- > Michal Hocko > SUSE Labs
On 2023/6/8 18:13, Mike Rapoport wrote: > On Thu, Jun 08, 2023 at 11:18:02AM +0200, Michal Hocko wrote: >> On Thu 08-06-23 15:38:48, Haifeng Xu wrote: >>> >>> >>> On 2023/6/7 18:22, David Hildenbrand wrote: >>>> On 07.06.23 12:16, Michal Hocko wrote: >>>>> On Wed 07-06-23 09:07:34, Haifeng Xu wrote: >>>>>> If freesize is less than dma_reserve, print warning message to report >>>>>> this case. >>>>> >>>>> Why? >>>> >>>> I'd like to second that question, and add >>>> >>>> a) Did you run into that scenario? >>>> b) What can an admin do in that case with that error messages? >>> >>> In theory,dma_reserve shouldn't exceed freesize, so the error messages can remind us >>> to verify whether the configuration of reserved memory is correct. >> >> I am not really convinced this is worth touching the code TBH. > > The only architecture that sets the dma_reserve is x86_64 and it sets it to > the number of reserved pages in DMA zone. There is no way freesize will be > less than dma_reserve. Yes. From the comments, x86_64 calculates the dma_reserve in order to set zone watermarks more accurately. But berfore init_per_zone_wmark_min(), memblock_free_all() has already recalculated the managed pages. It seems that the dma_reserve is not really helpful to this. > > I'm not sure that in general dma_reserve has some value now, but that's a > completely different story. > >> -- >> Michal Hocko >> SUSE Labs >
diff --git a/mm/mm_init.c b/mm/mm_init.c index 232efac9a929..9a9d6a52471c 100644 --- a/mm/mm_init.c +++ b/mm/mm_init.c @@ -1561,9 +1561,14 @@ static void __init free_area_init_core(struct pglist_data *pgdat) } /* Account for reserved pages */ - if (j == 0 && freesize > dma_reserve) { - freesize -= dma_reserve; - pr_debug(" %s zone: %lu pages reserved\n", zone_names[0], dma_reserve); + if (j == 0) { + if (freesize >= dma_reserve) { + freesize -= dma_reserve; + pr_debug(" %s zone: %lu pages reserved\n", + zone_names[0], dma_reserve); + } else + pr_warn(" %s zone: %lu reserved pages exceeds freesize %lu\n", + zone_names[0], dma_reserve, freesize); } if (!is_highmem_idx(j))