Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp5551155imm; Mon, 23 Jul 2018 01:32:32 -0700 (PDT) X-Google-Smtp-Source: AAOMgpfNcPpTbrEJ6jakIyvobFyF03sFDqkQOXDvQTp6nbfVtIPUuEsm9yf9ViGqOl6/R8yws5AO X-Received: by 2002:a17:902:143:: with SMTP id 61-v6mr11906590plb.171.1532334752004; Mon, 23 Jul 2018 01:32:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1532334751; cv=none; d=google.com; s=arc-20160816; b=S3cHVXli0hLX/EiByFFjOOP95gkDiPbn/4MgsDEfutpb+Z6sjM2r1/cqlfz0yc2V/P JtZERwuV7RkQTs9RREY5sYbCx693Oa08FqXdA3zCcoYXiQ8X1sXKZfYA2YfLgdTV7l+N GegiX2a1/EeDOR3Fl2yAaedVPdl2w/CF+cC3G2SwqpT5OEt96r3yzlTOqHE5+vrCn0OO skv3VJXSA0ryqb5Edowyaag6bdQciYhE2C7y3HsggrrwSveVHOFHQPsNGBLq4WHEobhw Drx16G8rF7NubnE/21JhFJ28XDikHe7TCyVFoLIX/tS8V2Nyr2YIor9nHQJTc4oIF47Q ZUUg== 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:message-id:subject:cc :to:from:date:arc-authentication-results; bh=EhrTXKA4UkEVw+/SjKHOro4j4oFFZPUFTFOeZw9554o=; b=bobsTu3DVuVgGX5734JLMPfnGK8PAxSHJK52dKChmZZcb6Rk9Ggbu1mrV1WaQl6Iht X9Uml3bVuhZF0F0J6F0KnY9toEsbWRstixNZsS1VYOjXcUTFLe0UX17cr7LtraGF7VoE goEzSDb8KLOij6h5GYFnPUTwVcm89h28hG24ThCvhhCICIP6ptiYvbjiNfoA97tTTKhV vQCWujTypykqV/upJ7jG0iMc3YlpoqAmIMC+RfCHOqAEPmdKrkdMEiGHgPMKXerzNWqA wm6IpUBh4JwFegpSSfIo279kL7XWl1XDMEErGSs30/kLZmP/HOB3fTg1NhBPwycM07Q/ n2Rg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id bd3-v6si7482561plb.171.2018.07.23.01.32.17; Mon, 23 Jul 2018 01:32:31 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388066AbeGWJau (ORCPT + 99 others); Mon, 23 Jul 2018 05:30:50 -0400 Received: from mx2.suse.de ([195.135.220.15]:56146 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S2387908AbeGWJat (ORCPT ); Mon, 23 Jul 2018 05:30:49 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay1.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id C12EFAE7B; Mon, 23 Jul 2018 08:30:44 +0000 (UTC) Date: Mon, 23 Jul 2018 10:30:43 +0200 From: Michal Hocko To: Oscar Salvador Cc: akpm@linux-foundation.org, pasha.tatashin@oracle.com, vbabka@suse.cz, aaron.lu@intel.com, iamjoonsoo.kim@lge.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, Oscar Salvador Subject: Re: [PATCH v2 3/5] mm/page_alloc: Optimize free_area_init_core Message-ID: <20180723083043.GF17905@dhcp22.suse.cz> References: <20180719132740.32743-1-osalvador@techadventures.net> <20180719132740.32743-4-osalvador@techadventures.net> <20180719134417.GC7193@dhcp22.suse.cz> <20180719140327.GB10988@techadventures.net> <20180719151555.GH7193@dhcp22.suse.cz> <20180719205235.GA14010@techadventures.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180719205235.GA14010@techadventures.net> User-Agent: Mutt/1.10.0 (2018-05-17) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu 19-07-18 22:52:35, Oscar Salvador wrote: > On Thu, Jul 19, 2018 at 05:15:55PM +0200, Michal Hocko wrote: > > Your changelog doesn't really explain the motivation. Does the change > > help performance? Is this a pure cleanup? > > Hi Michal, > > Sorry to not have explained this better from the very beginning. > > It should help a bit in performance terms as we would be skipping those > condition checks and assignations for zones that do not have any pages. > It is not a huge win, but I think that skipping code we do not really need to run > is worh to have. It is always preferable to have numbers when you are claiming performance benefits. > > > The function is certainly not an example of beauty. It is more an > > example of changes done on top of older ones without much thinking. But > > I do not see your change would make it so much better. I would consider > > it a much nicer cleanup if it was split into logical units each doing > > one specific thing. > > About the cleanup, I thought that moving that block of code to a separate function > would make the code easier to follow. > If you think that this is still not enough, I can try to split it and see the outcome. Well, on the other hand, is the change really worth it? Moving code around is not free either. Any git blame tracking to understand why the code is done this way will be harder. But just to make it clear, I do not want to discourage you from touching this area. I just believe that if you really want to do that then the result shouldn't just tweak one specific case and tweak it. It would be much more appreciated if the new code had much better structure and less hacks. -- Michal Hocko SUSE Labs