Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp1160386pxu; Fri, 27 Nov 2020 00:50:08 -0800 (PST) X-Google-Smtp-Source: ABdhPJztgA+XhM+QTSUphtiHkGeLqi1EKS/TXk43HTKDpgGfpbFoeB827X/gOde1zH/7sp+Dalgq X-Received: by 2002:a05:6402:1844:: with SMTP id v4mr6326473edy.346.1606467008702; Fri, 27 Nov 2020 00:50:08 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1606467008; cv=none; d=google.com; s=arc-20160816; b=Fr8TM8cxUUe9d2teUA5z83cdHPdD65TRnw1Qt+m7uKoVuveMtzAGfFrYMzn3C2HGJe W5P9krFdfSzvYg8CF7QCKWgKu/Cd6Kl/spsCWBubu2fb2Rh37rBkiPgmljuGOzGjppGY VFmmmEY1xOPXp3hWGl2YECnqPDKKCod9CYuzJgxxch4uaFunOIxjdTzVkOigVtQV1ZN2 dksn/uRRbMWjafGfF8WGh3fGJ3kkSl3RqnU97rfNahoYs9RxagrkzOKG6+IDA8OOkr2q vpBervm5/2Aqa+GDfVO/Hv3fekqTVfTFXsa5TPe40x4Wt+aZeb/tWhqPnssw7P14ZYms fthQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to :mime-version:user-agent:date:message-id:from:references:cc:to :subject; bh=xGQORpn2gMz7VvbCWa2ozCcMzcyMg4v2fnsI2nBRKNI=; b=ZlcKe4ebTSxD2dtsUUTWRMfdstPIlLQ7+7SeoblCF2I8CbrV535Km8l7w3aTAuQrtS SODWZh8xQf+yD+8pwqA+A8BGB5QMn77sfFFY64b7rabl5MnXCCLJDToq5PS+9mvEi9sV HBaoAx86dNwV3YlMyhfwVBiGKqmGRGAEw0zyxWt+CoCi+gfxWAQeZXieCdNKeR/SVEsi 0+1tkcR1dkNf/uj6B92SZDGtbkeKIC4wlD2FCmAaqjTgBCC5xGiWmNBVkl/ZPGECiGci UnqHjzqOHd9+7WJBl/ThFjLnmyb70HDgGlLUIW8v85BqURvVD+5FlofZs/bS2+NMyGOj emOQ== ARC-Authentication-Results: i=1; mx.google.com; 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=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id m17si4514560ejn.194.2020.11.27.00.49.46; Fri, 27 Nov 2020 00:50:08 -0800 (PST) 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; 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=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2392167AbgK0B4L (ORCPT + 99 others); Thu, 26 Nov 2020 20:56:11 -0500 Received: from out30-54.freemail.mail.aliyun.com ([115.124.30.54]:50049 "EHLO out30-54.freemail.mail.aliyun.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727441AbgK0B4K (ORCPT ); Thu, 26 Nov 2020 20:56:10 -0500 X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R501e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e01e04400;MF=alex.shi@linux.alibaba.com;NM=1;PH=DS;RN=8;SR=0;TI=SMTPD_---0UGdzEzw_1606442166; Received: from IT-FVFX43SYHV2H.local(mailfrom:alex.shi@linux.alibaba.com fp:SMTPD_---0UGdzEzw_1606442166) by smtp.aliyun-inc.com(127.0.0.1); Fri, 27 Nov 2020 09:56:07 +0800 Subject: Re: [PATCH next] mm/vmscan: __isolate_lru_page_prepare clean up To: Vlastimil Babka , Andrew Morton Cc: Matthew Wilcox , Hugh Dickins , Yu Zhao , Michal Hocko , linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <1605859413-53864-1-git-send-email-alex.shi@linux.alibaba.com> <20201120151307.4d9e3ef092ba01a325db7ce2@linux-foundation.org> <20201122123552.GF4327@casper.infradead.org> <728874d7-2d93-4049-68c1-dcc3b2d52ccd@linux.alibaba.com> <46ad053f-1401-31e8-50cf-09acda588f6f@suse.cz> <20201125154346.b2032c39cf3905bbebec3322@linux-foundation.org> <2ba66325-e3c8-d809-a8dd-85af77c3904b@suse.cz> From: Alex Shi Message-ID: <166d0496-a304-5005-e14d-1963389b558b@linux.alibaba.com> Date: Fri, 27 Nov 2020 09:56:06 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <2ba66325-e3c8-d809-a8dd-85af77c3904b@suse.cz> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 在 2020/11/26 下午11:23, Vlastimil Babka 写道: >>> >>> I tried that, and .text became significantly larger, for reasons which >>> I didn't investigate ;) > > I found out that comparing whole .text doesn't often work as changes might be lost in alignment, or > once in a while cross the alignment boundary and become exagerated. bloat-o-meter works nice though. > >> Uh, BTW, with the gcc 8.3.1 and centos 7, goto or continue version has same size >> on my side with or w/o DEBUG_LIST. But actually, this clean up patch could >> add 10 bytes also with or w/o DEDBUG_LIST. >> >> Maybe related with different compiler? > > gcc (SUSE Linux) 10.2.1 20201117 [revision 98ba03ffe0b9f37b4916ce6238fad754e00d720b] > > ./scripts/bloat-o-meter vmscan.o.before mm/vmscan.o > add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-1 (-1) > Function                                     old     new   delta > isolate_lru_pages                           1125    1124      -1 > Total: Before=57283, After=57282, chg -0.00% > > Not surprising, as I'd expect the compiler to figure out by itself that list_move + continue > repeats and can be unified.  The reason for goto to stay would be rather readability (subjective). Hi Vlastimil, Thanks for tool sharing! The gcc do give different. My data is read from 'size' tool and isolate_lru_pages text size from 'objdump -d'. Maybe a same way like bloat-o-meter. :) Thanks Alex