From patchwork Sat Jul 11 02:34:59 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Rohit Sarkar X-Patchwork-Id: 1327209 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from lists.ozlabs.org (lists.ozlabs.org [203.11.71.2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 4B3Yst0Mwfz9sDX for ; Sat, 11 Jul 2020 12:35:14 +1000 (AEST) Authentication-Results: ozlabs.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20161025 header.b=AIu4P0Ws; dkim-atps=neutral Received: from bilbo.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3]) by lists.ozlabs.org (Postfix) with ESMTP id 4B3Yss4h9GzDrCG for ; Sat, 11 Jul 2020 12:35:13 +1000 (AEST) X-Original-To: patchwork@lists.ozlabs.org Delivered-To: patchwork@lists.ozlabs.org Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=gmail.com (client-ip=2607:f8b0:4864:20::442; helo=mail-pf1-x442.google.com; envelope-from=rohitsarkar5398@gmail.com; receiver=) Authentication-Results: lists.ozlabs.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20161025 header.b=AIu4P0Ws; dkim-atps=neutral Received: from mail-pf1-x442.google.com (mail-pf1-x442.google.com [IPv6:2607:f8b0:4864:20::442]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4B3Ysl2PkYzDr0f for ; Sat, 11 Jul 2020 12:35:06 +1000 (AEST) Received: by mail-pf1-x442.google.com with SMTP id u18so3332582pfk.10 for ; Fri, 10 Jul 2020 19:35:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=message-id:date:from:to:cc:subject:mime-version:content-disposition :user-agent; bh=akKbaWqo9PTTWZkX95d6Y+FTAGZeZf0NCWFbbx5O8RY=; b=AIu4P0WsDFUNH1GRMGBvOmhEI2hpFaV+yNhRxI5apZgHT/LGIgpXlKSUXwInaLfFS8 p+wdNcLjuTcwAKzpVhlu5SwLd4q0gLvml4LpEfwgcU8zUWzijcjD7Q9PsQBCh9ETb3De E09Jj70yB6M3wf/jq/roGrbmhzJ9BQq/I7dGAbxjHOVQXNt/RFFCGZzHjn/6k4lLvgeh fpqlA+3lHAmaFPGLBtvUryJ/BVUDTOaD4I2Amu3JhIks9Nl6e6DKyKQ6mVFKI0VXDq5P FBQMSnR3+ZKPTuT4Ll+kIGllz3jSqtqgcBpK+qO8lCU60GeWsv8U0ufmJhdTVix3+Nuz xrqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:date:from:to:cc:subject:mime-version :content-disposition:user-agent; bh=akKbaWqo9PTTWZkX95d6Y+FTAGZeZf0NCWFbbx5O8RY=; b=Oik++R/o9kRUHv76rGkrd2j7VsEUG1AoYiYqPAZ1277CpGPJyQ1U2RZwzYWCiI2FV3 mYhL6YKSxoP1RqI5skfwZK2QjoXghJ8bgkpZCIug0ZJpL2vkU6/vLR+cUMm3yt/6Z5G9 h/KZ8I7NVAknD/FXxb63n00hbv6gaIHeJM0IFXRWubId44A+NI+G7LU4c7qaJJngj6rd 9O1GWtqAVpECotrF7vrUNBmwntp23K8Ga9bSHMpqI3LeJA8zhykZyVvgzMlb6033ZG4e cAkzedodEW3IsGRskkcMnQ48xQ1Nyzz4ZpdMhTLhc9w8xnBj6LRCLKK6leYTtXWRwh9w tIVw== X-Gm-Message-State: AOAM5325ZwG9boXC53eKnU299Aefc/rVFH4OVka3zQu6zstGSCQauYMH BS/kuZA3dsw5sM/clOLHz+U= X-Google-Smtp-Source: ABdhPJy0xv/Yl+RPOWqq93IfuzNXBpoHoOZ7OZ5nHypCDq54Xc/fBBND+g24BxpvuQMrAjoIqQUMkg== X-Received: by 2002:a63:3409:: with SMTP id b9mr62716338pga.106.1594434903208; Fri, 10 Jul 2020 19:35:03 -0700 (PDT) Received: from SARKAR ([103.252.171.50]) by smtp.gmail.com with ESMTPSA id mg17sm6935128pjb.55.2020.07.10.19.35.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 10 Jul 2020 19:35:02 -0700 (PDT) Message-ID: <5f092556.1c69fb81.abd16.0d8b@mx.google.com> X-Google-Original-Message-ID: <20200711023459.GA11638@rohitsarkar5398@gmail.com> Date: Sat, 11 Jul 2020 08:04:59 +0530 From: Rohit Sarkar To: patchwork@lists.ozlabs.org Subject: [bug?] dumparchive behaviour MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.9.4 (2018-02-28) X-BeenThere: patchwork@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Patchwork development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: ralf.ramsauer@oth-regensburg.de Errors-To: patchwork-bounces+incoming=patchwork.ozlabs.org@lists.ozlabs.org Sender: "Patchwork" Hey, While using dumparchive on a Patchwork instance with some patches from the linux-mm mailing list I noticed something weird in the mbox archive generated. Some patches dont contain a patchwork id or message id in the dump, but I noticed what seemed like a duplicate patch in the same dump which does contain both. Attaching an extract from the archive for reference. In the extract the first patch does contain both the ids, but the second doesnt. Is the second one required in the dump? If so shouldnt it have the respective ids. Thanks, Rohit From patchwork Mon Jan 4 05:52:36 2010 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: KOSAKI Motohiro X-Patchwork-Id: 10690 Return-Path: Received: from mail172.messagelabs.com (mail172.messagelabs.com [216.82.254.3]) by kanga.kvack.org (Postfix) with SMTP id 3F61B600068 for ; Mon, 4 Jan 2010 00:52:41 -0500 (EST) Received: from m6.gw.fujitsu.co.jp ([10.0.50.76]) by fgwmail6.fujitsu.co.jp (Fujitsu Gateway) with ESMTP id o045qbnQ014218 for (envelope-from kosaki.motohiro@jp.fujitsu.com); Mon, 4 Jan 2010 14:52:38 +0900 Received: from smail (m6 [127.0.0.1]) by outgoing.m6.gw.fujitsu.co.jp (Postfix) with ESMTP id 9D5B045DE50 for ; Mon, 4 Jan 2010 14:52:37 +0900 (JST) Received: from s6.gw.fujitsu.co.jp (s6.gw.fujitsu.co.jp [10.0.50.96]) by m6.gw.fujitsu.co.jp (Postfix) with ESMTP id 6FB6145DE4C for ; Mon, 4 Jan 2010 14:52:37 +0900 (JST) Received: from s6.gw.fujitsu.co.jp (localhost.localdomain [127.0.0.1]) by s6.gw.fujitsu.co.jp (Postfix) with ESMTP id 4C2801DB803F for ; Mon, 4 Jan 2010 14:52:37 +0900 (JST) Received: from m105.s.css.fujitsu.com (m105.s.css.fujitsu.com [10.249.87.105]) by s6.gw.fujitsu.co.jp (Postfix) with ESMTP id F2E261DB8037 for ; Mon, 4 Jan 2010 14:52:36 +0900 (JST) From: KOSAKI Motohiro Subject: [PATCH] page allocator: fix update NR_FREE_PAGES only as necessary In-Reply-To: <20100104122138.f54b7659.minchan.kim@barrios-desktop> References: <1262571730-2778-1-git-send-email-shijie8@gmail.com> <20100104122138.f54b7659.minchan.kim@barrios-desktop> Message-Id: <20100104144332.96A2.A69D9226@jp.fujitsu.com> MIME-Version: 1.0 Date: Mon, 4 Jan 2010 14:52:36 +0900 (JST) Sender: owner-linux-mm@kvack.org To: Minchan Kim Cc: kosaki.motohiro@jp.fujitsu.com, Huang Shijie , akpm@linux-foundation.org, mel@csn.ul.ie, linux-mm@kvack.org List-ID: > Hi, Huang. > > On Mon, 4 Jan 2010 10:22:10 +0800 > Huang Shijie wrote: > > > When the `page' returned by __rmqueue() is NULL, the origin code > > still adds -(1 << order) to zone's NR_FREE_PAGES item. > > > > The patch fixes it. > > > > Signed-off-by: Huang Shijie > > --- > > mm/page_alloc.c | 10 +++++++--- > > 1 files changed, 7 insertions(+), 3 deletions(-) > > > > diff --git a/mm/page_alloc.c b/mm/page_alloc.c > > index 4e9f5cc..620921d 100644 > > --- a/mm/page_alloc.c > > +++ b/mm/page_alloc.c > > @@ -1222,10 +1222,14 @@ again: > > } > > spin_lock_irqsave(&zone->lock, flags); > > page = __rmqueue(zone, order, migratetype); > > - __mod_zone_page_state(zone, NR_FREE_PAGES, -(1 << order)); > > - spin_unlock(&zone->lock); > > - if (!page) > > + if (likely(page)) { > > + __mod_zone_page_state(zone, NR_FREE_PAGES, > > + -(1 << order)); > > + spin_unlock(&zone->lock); > > + } else { > > + spin_unlock(&zone->lock); > > goto failed; > > + } > > } > > > > __count_zone_vm_events(PGALLOC, zone, 1 << order); > > I think it's not desirable to add new branch in hot-path even though > we could avoid that. > > How about this? > > diff --git a/mm/page_alloc.c b/mm/page_alloc.c > index 4e4b5b3..87976ad 100644 > --- a/mm/page_alloc.c > +++ b/mm/page_alloc.c > @@ -1244,6 +1244,9 @@ again: > return page; > > failed: > + spin_lock(&zone->lock); > + __mod_zone_page_state(zone, NR_FREE_PAGES, 1 << order); > + spin_unlock(&zone->lock); > local_irq_restore(flags); > put_cpu(); > return NULL; Why can't we write following? __mod_zone_page_state() only require irq disabling, it doesn't need spin lock. I think. From 72011ff2b0bba6544ae35c6ee52715c8c824a34b Mon Sep 17 00:00:00 2001 From: KOSAKI Motohiro Date: Mon, 4 Jan 2010 14:38:20 +0900 Subject: [PATCH] page allocator: fix update NR_FREE_PAGES only as necessary commit f2260e6b (page allocator: update NR_FREE_PAGES only as necessary) made one minor regression. if __rmqueue() was failed, NR_FREE_PAGES stat go wrong. this patch fixes it. Signed-off-by: KOSAKI Motohiro Cc: Mel Gorman Cc: Huang Shijie Cc: Minchan Kim --- mm/page_alloc.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/mm/page_alloc.c b/mm/page_alloc.c index 11ae66e..ecf75a1 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -1227,10 +1227,10 @@ again: } spin_lock_irqsave(&zone->lock, flags); page = __rmqueue(zone, order, migratetype); - __mod_zone_page_state(zone, NR_FREE_PAGES, -(1 << order)); spin_unlock(&zone->lock); if (!page) goto failed; + __mod_zone_page_state(zone, NR_FREE_PAGES, -(1 << order)); } __count_zone_vm_events(PGALLOC, zone, 1 << order);