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=-8.5 required=3.0 tests=INCLUDES_PATCH, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=ham 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 842FDCA9EB6 for ; Wed, 23 Oct 2019 18:01:25 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 4EEAA2086D for ; Wed, 23 Oct 2019 18:01:25 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4EEAA2086D Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 028E36B0006; Wed, 23 Oct 2019 14:01:25 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id F1B296B0008; Wed, 23 Oct 2019 14:01:24 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E31666B000A; Wed, 23 Oct 2019 14:01:24 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0223.hostedemail.com [216.40.44.223]) by kanga.kvack.org (Postfix) with ESMTP id C1C696B0006 for ; Wed, 23 Oct 2019 14:01:24 -0400 (EDT) Received: from smtpin04.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with SMTP id 65978180AD5C5 for ; Wed, 23 Oct 2019 18:01:24 +0000 (UTC) X-FDA: 76075816488.04.hill07_6389dc3f1195e X-HE-Tag: hill07_6389dc3f1195e X-Filterd-Recvd-Size: 4213 Received: from mx1.suse.de (mx2.suse.de [195.135.220.15]) by imf03.hostedemail.com (Postfix) with ESMTP for ; Wed, 23 Oct 2019 18:01:23 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id A13E4AD46; Wed, 23 Oct 2019 18:01:22 +0000 (UTC) Date: Wed, 23 Oct 2019 20:01:21 +0200 From: Michal Hocko To: Waiman Long Cc: Andrew Morton , Mel Gorman , linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-api@vger.kernel.org, Johannes Weiner , Roman Gushchin , Vlastimil Babka , Konstantin Khlebnikov , Jann Horn , Song Liu , Greg Kroah-Hartman , Rafael Aquini Subject: Re: [PATCH 1/2] mm, vmstat: Release zone lock more frequently when reading /proc/pagetypeinfo Message-ID: <20191023180121.GN17610@dhcp22.suse.cz> References: <20191023102737.32274-3-mhocko@kernel.org> <20191023173423.12532-1-longman@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191023173423.12532-1-longman@redhat.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed 23-10-19 13:34:22, Waiman Long wrote: > With a threshold of 100000, it is still possible that the zone lock > will be held for a very long time in the worst case scenario where all > the counts are just below the threshold. With up to 6 migration types > and 11 orders, it means up to 6.6 millions. > > Track the total number of list iterations done since the acquisition > of the zone lock and release it whenever 100000 iterations or more have > been completed. This will cap the lock hold time to no more than 200,000 > list iterations. > > Signed-off-by: Waiman Long > --- > mm/vmstat.c | 18 ++++++++++++++---- > 1 file changed, 14 insertions(+), 4 deletions(-) > > diff --git a/mm/vmstat.c b/mm/vmstat.c > index 57ba091e5460..c5b82fdf54af 100644 > --- a/mm/vmstat.c > +++ b/mm/vmstat.c > @@ -1373,6 +1373,7 @@ static void pagetypeinfo_showfree_print(struct seq_file *m, > pg_data_t *pgdat, struct zone *zone) > { > int order, mtype; > + unsigned long iteration_count = 0; > > for (mtype = 0; mtype < MIGRATE_TYPES; mtype++) { > seq_printf(m, "Node %4d, zone %8s, type %12s ", > @@ -1397,15 +1398,24 @@ static void pagetypeinfo_showfree_print(struct seq_file *m, > * of pages in this order should be more than > * sufficient > */ > - if (++freecount >= 100000) { > + if (++freecount > 100000) { > overflow = true; > - spin_unlock_irq(&zone->lock); > - cond_resched(); > - spin_lock_irq(&zone->lock); > + freecount--; > break; > } > } > seq_printf(m, "%s%6lu ", overflow ? ">" : "", freecount); > + /* > + * Take a break and release the zone lock when > + * 100000 or more entries have been iterated. > + */ > + iteration_count += freecount; > + if (iteration_count >= 100000) { > + iteration_count = 0; > + spin_unlock_irq(&zone->lock); > + cond_resched(); > + spin_lock_irq(&zone->lock); > + } Aren't you overengineering this a bit? If you are still worried then we can simply cond_resched for each order diff --git a/mm/vmstat.c b/mm/vmstat.c index c156ce24a322..ddb89f4e0486 100644 --- a/mm/vmstat.c +++ b/mm/vmstat.c @@ -1399,13 +1399,13 @@ static void pagetypeinfo_showfree_print(struct seq_file *m, */ if (++freecount >= 100000) { overflow = true; - spin_unlock_irq(&zone->lock); - cond_resched(); - spin_lock_irq(&zone->lock); break; } } seq_printf(m, "%s%6lu ", overflow ? ">" : "", freecount); + spin_unlock_irq(&zone->lock); + cond_resched(); + spin_lock_irq(&zone->lock); } seq_putc(m, '\n'); } I do not have a strong opinion here but I can fold this into my patch 2. -- Michal Hocko SUSE Labs