Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp1805003ybz; Thu, 23 Apr 2020 06:17:58 -0700 (PDT) X-Google-Smtp-Source: APiQypIFKg/81AQvNjaIwhUpD9sTjWJl6uYFzOmDpdTT4gwqSEqFqSUo0o7FX7UoYLmExVewVXGk X-Received: by 2002:a17:906:5918:: with SMTP id h24mr2663064ejq.210.1587647877816; Thu, 23 Apr 2020 06:17:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1587647877; cv=none; d=google.com; s=arc-20160816; b=Ux2ZuefLb+ZvFtSgaL/+FNikSysvZUynvVvLhiMvm0EhLEJdP/chhQtTHgWGiaXKJE 1TdvYZP91RvMJVo2AfDZ43J2tFIJOHm6zOa279xPc7eelZkBI7e5ra5sZuCvE+Ig7A9l T1HzYApMIAaEK7hUhVrW2Oq9qwExLyLiEizIwz7y11GS6WRagRIGWwzFsEEOxvqzDC9N 0GSD8mCoZmfYsLJTaSwxMw7EcBP2B6xYMwICySpq0NhM2AnI/iR52XHiGli9ud1BvzfA JIpfXcYIP7w/fORhtIgAtFsmv/uTuK/AiS+AUEPrSWh+B4t/sKoaIFB4v4+asz3p4a5B pG9A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:reply-to:message-id :subject:cc:to:from:date:dkim-signature; bh=3Zo7rnxcWhUpGEGC0nWboNyq0EHY811ymcRqQTZrBts=; b=OEVHo3A6/K4K2+uUhRpJbKg63lXnRcAxln69pCQXckToWr5xFIvgdP18/F1UKjAKG7 zDU4qZnBZ0k1zutPPiV+emyyA6dOHMk5uZ1An2RgQKvu/X/h0PwN0WyGF9MXufjNH5V+ MhU25nKDXAJWRe4Ts/CsNGwPWDRfthoepDE6cEHzkS5tm32ucya3JTlGXUUtsmh4f+nV +lBlsNs98Su2vSlLSNsT0mOVTn+hlpHG1kPMttJToed2Erl757SpCqtpQsJ8UhK1pcag RqOBwPtJTm87tEEPKM49L8oMxAJgnWPHOW5DnyZ/ZapatFsXLa+9VTRazhZVMpQNdiuh CqQg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=WCR0glYL; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id g15si1096545edr.14.2020.04.23.06.17.34; Thu, 23 Apr 2020 06:17:57 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=WCR0glYL; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726780AbgDWNPL (ORCPT + 99 others); Thu, 23 Apr 2020 09:15:11 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60392 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1726361AbgDWNPK (ORCPT ); Thu, 23 Apr 2020 09:15:10 -0400 Received: from mail-wr1-x443.google.com (mail-wr1-x443.google.com [IPv6:2a00:1450:4864:20::443]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 79A60C08E934 for ; Thu, 23 Apr 2020 06:15:10 -0700 (PDT) Received: by mail-wr1-x443.google.com with SMTP id i10so6784808wrv.10 for ; Thu, 23 Apr 2020 06:15:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:reply-to:references:mime-version :content-disposition:in-reply-to:user-agent; bh=3Zo7rnxcWhUpGEGC0nWboNyq0EHY811ymcRqQTZrBts=; b=WCR0glYLeRqbNhxoWsBzFO6l5UUoaRoxjdKWZ2MbdNINhaKIRJRId4i1CXLryvSX2J z50vjVbdsB3EY59IywGT9xwebLEOHe3JouFr2pdgeJMGsvdX3QOsU/HWkdo3srqny1wh dqagNUm/QvHATmeU9aSJ1mpLMjIUo3/bZOMf4oXQ4ZcGf/WXCy8VXC5u/S890rSTrFuU 0DBprcOdiRZ+hAqv/KzJBUFGYHpPmfh4NLDNzQsXhrNaWLpFX7SexeabHNSnDL3BitBH lYRjA9tZqMztK1Ky73ezr1OzrNBk9fm6Dp1cdbhgakwVF28lSgDfWSjGCbLXv2NPKsRC B5fQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:reply-to :references:mime-version:content-disposition:in-reply-to:user-agent; bh=3Zo7rnxcWhUpGEGC0nWboNyq0EHY811ymcRqQTZrBts=; b=Bn13JlSfp/qGEMb5tZxOkpDzgh1N4fs3D6iSi24YU9JMav37RWwYWmR6BB4H3XvYkf DI4Kxf5YdJvbMPmhxdpcSaRvk25EADn2ovwfxqwTPJYdF5z/t51i98MCwbmwynnn7UeB hJthm0UkrFK/EkVLDq3vh4QIxEl9uoYqRph1vn+PJ6O5WYm9UW5hiiLJUJsbSc+y8R2v aBcc58wYgUhfLqfl8qaMoeCN6ZEZ5voFntqZch88giwHv4q1JC1mVJsNt+eLYgWcGvVg owNBwL3FGdagj+jiAudg5Tz0nbgx9YHFwCkhnzunxtuQmpOQ9old+5cSrPayWgbshuGw 3OTQ== X-Gm-Message-State: AGi0PuYnVVPAZv2Sqx/uF817s3gXNIt1d7BunaBA6y572L2mBJWK/Fs+ OVJv/IMCgnHGw0epzFMlhrY= X-Received: by 2002:a05:6000:1242:: with SMTP id j2mr4830499wrx.274.1587647709238; Thu, 23 Apr 2020 06:15:09 -0700 (PDT) Received: from localhost ([185.92.221.13]) by smtp.gmail.com with ESMTPSA id 1sm3588747wmz.13.2020.04.23.06.15.08 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Thu, 23 Apr 2020 06:15:08 -0700 (PDT) Date: Thu, 23 Apr 2020 13:15:07 +0000 From: Wei Yang To: "Huang, Ying" Cc: Wei Yang , akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Hugh Dickins Subject: Re: [PATCH v2] mm/swapfile.c: simplify the scan loop in scan_swap_map_slots() Message-ID: <20200423131507.2rgrk3okh42oo6gh@master> Reply-To: Wei Yang References: <20200422214111.19370-1-richard.weiyang@gmail.com> <87d07y2181.fsf@yhuang-dev.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87d07y2181.fsf@yhuang-dev.intel.com> User-Agent: NeoMutt/20170113 (1.7.2) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Apr 23, 2020 at 01:57:34PM +0800, Huang, Ying wrote: >Wei Yang writes: > >> After commit c60aa176c6de8 ("swapfile: swap allocation cycle if >> nonrot"), swap allocation is cyclic. Current approach is done with two >> separate loop on the upper and lower half. This looks a little >> redundant. > >I can understand that the redundant code doesn't smell good. But I >don't think the new code is easier to be understood than the original >one. > >> From another point of view, the loop iterates [lowest_bit, highest_bit] >> range starting with (offset + 1) but except scan_base. So we can >> simplify the loop with condition (next_offset() != scan_base) by >> introducing next_offset() which makes sure offset fit in that range >> with correct order. >> >> Signed-off-by: Wei Yang >> CC: Hugh Dickins >> CC: "Huang, Ying" >> >> --- >> v2: >> * return scan_base if the lower part is eaten >> * only start over when iterating on the upper part >> --- >> mm/swapfile.c | 31 ++++++++++++++----------------- >> 1 file changed, 14 insertions(+), 17 deletions(-) >> >> diff --git a/mm/swapfile.c b/mm/swapfile.c >> index f903e5a165d5..0005a4a1c1b4 100644 >> --- a/mm/swapfile.c >> +++ b/mm/swapfile.c >> @@ -729,6 +729,19 @@ static void swap_range_free(struct swap_info_struct *si, unsigned long offset, >> } >> } >> >> +static unsigned long next_offset(struct swap_info_struct *si, >> + unsigned long *offset, unsigned long scan_base) >> +{ >> + /* only start over when iterating on the upper part */ >> + if (++(*offset) > si->highest_bit && *offset > scan_base) { >> + *offset = si->lowest_bit; >> + /* someone has eaten the lower part */ >> + if (si->lowest_bit >= scan_base) >> + return scan_base; >> + } > >if "offset > si->highest_bit" is true and "offset < scan_base" is true, >scan_base need to be returned. > When this case would happen in the original code? >Again, the new code doesn't make it easier to find this kind of issues. > >Best Regards, >Huang, Ying -- Wei Yang Help you, Help me