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=-5.6 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,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 A7CA5C49ED6 for ; Tue, 10 Sep 2019 12:20:34 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 73D98208E4 for ; Tue, 10 Sep 2019 12:20:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1568118034; bh=VyFjngry8JwUDlxLugcWXUNSbKo9DlhhJow8lZ9dJFs=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=t/lR+8HDR7tCsZtvVzpHHKEUa1JJSXY+hfYnXhAMtEVmCV+ZAlT+TCzteRnqo52Av QVmS62ACeepXLUflxIOQ5Rs95FdSOpPH0oj9Z0a9BmuAID+EkamtfwzoxwOlUB7e+F LMso+3YqVqb8MwXW18n+NJto6040lMPB/Cj3L+4w= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388733AbfIJMUd (ORCPT ); Tue, 10 Sep 2019 08:20:33 -0400 Received: from mx2.suse.de ([195.135.220.15]:48852 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1731146AbfIJMUd (ORCPT ); Tue, 10 Sep 2019 08:20:33 -0400 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 80E9FABCE; Tue, 10 Sep 2019 12:20:31 +0000 (UTC) Date: Tue, 10 Sep 2019 14:20:30 +0200 From: Michal Hocko To: Alexander Duyck Cc: virtio-dev@lists.oasis-open.org, kvm@vger.kernel.org, mst@redhat.com, catalin.marinas@arm.com, david@redhat.com, dave.hansen@intel.com, linux-kernel@vger.kernel.org, willy@infradead.org, linux-mm@kvack.org, akpm@linux-foundation.org, will@kernel.org, linux-arm-kernel@lists.infradead.org, osalvador@suse.de, yang.zhang.wz@gmail.com, pagupta@redhat.com, konrad.wilk@oracle.com, nitesh@redhat.com, riel@surriel.com, lcapitulino@redhat.com, wei.w.wang@intel.com, aarcange@redhat.com, ying.huang@intel.com, pbonzini@redhat.com, dan.j.williams@intel.com, fengguang.wu@intel.com, alexander.h.duyck@linux.intel.com, kirill.shutemov@linux.intel.com Subject: Re: [PATCH v9 2/8] mm: Adjust shuffle code to allow for future coalescing Message-ID: <20190910122030.GV2063@dhcp22.suse.cz> References: <20190907172225.10910.34302.stgit@localhost.localdomain> <20190907172520.10910.83100.stgit@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190907172520.10910.83100.stgit@localhost.localdomain> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat 07-09-19 10:25:20, Alexander Duyck wrote: > From: Alexander Duyck > > Move the head/tail adding logic out of the shuffle code and into the > __free_one_page function since ultimately that is where it is really > needed anyway. By doing this we should be able to reduce the overhead > and can consolidate all of the list addition bits in one spot. This changelog doesn't really explain why we want this. You are reshuffling the code, allright, but why do we want to reshuffle? Is the result readability a better code reuse or something else? Where does the claimed reduced overhead coming from? >From a quick look buddy_merge_likely looks nicer than the code splat we have. Good. But then > Reviewed-by: Dan Williams > Signed-off-by: Alexander Duyck [...] > - if (is_shuffle_order(order)) > - add_to_free_area_random(page, &zone->free_area[order], > - migratetype); > + area = &zone->free_area[order]; > + if (is_shuffle_order(order) ? shuffle_pick_tail() : > + buddy_merge_likely(pfn, buddy_pfn, page, order)) Ouch this is just awful don't you think? -- Michal Hocko SUSE Labs