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=-2.6 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no 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 70599C49ED9 for ; Tue, 10 Sep 2019 17:45:58 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 44CED2171F for ; Tue, 10 Sep 2019 17:45:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1568137558; bh=nhozy1+SIp5fZkkmBLeMpwh1CRoYgJBvilyJiNcb0+k=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=2QI2bsppqxtDOwreGMCQjFXcHmD+SjZN6tWrhMZCRdkducwyw4AigGR4DlMocI20U d8E8JRtpv6aQ93Ypd7ReAtQ3507FTYFmQfiAPMpbVdTRFfgMt+tQdyDoJWzUxw/3gT yRfyccs5KHLEgd7Kg95CasEYET5zza0Cq6+3lSn8= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2437174AbfIJRp5 (ORCPT ); Tue, 10 Sep 2019 13:45:57 -0400 Received: from mx2.suse.de ([195.135.220.15]:44990 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S2437122AbfIJRp5 (ORCPT ); Tue, 10 Sep 2019 13:45:57 -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 E89D9AD17; Tue, 10 Sep 2019 17:45:54 +0000 (UTC) Date: Tue, 10 Sep 2019 19:45:53 +0200 From: Michal Hocko To: Alexander Duyck Cc: virtio-dev@lists.oasis-open.org, kvm list , "Michael S. Tsirkin" , Catalin Marinas , David Hildenbrand , Dave Hansen , LKML , Matthew Wilcox , linux-mm , Andrew Morton , will@kernel.org, linux-arm-kernel@lists.infradead.org, Oscar Salvador , Yang Zhang , Pankaj Gupta , Konrad Rzeszutek Wilk , Nitesh Narayan Lal , Rik van Riel , lcapitulino@redhat.com, "Wang, Wei W" , Andrea Arcangeli , ying.huang@intel.com, Paolo Bonzini , Dan Williams , Fengguang Wu , Alexander Duyck , "Kirill A. Shutemov" Subject: Re: [PATCH v9 3/8] mm: Move set/get_pcppage_migratetype to mmzone.h Message-ID: <20190910174553.GC4023@dhcp22.suse.cz> References: <20190907172225.10910.34302.stgit@localhost.localdomain> <20190907172528.10910.37051.stgit@localhost.localdomain> <20190910122313.GW2063@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 Tue 10-09-19 07:46:50, Alexander Duyck wrote: > On Tue, Sep 10, 2019 at 5:23 AM Michal Hocko wrote: > > > > On Sat 07-09-19 10:25:28, Alexander Duyck wrote: > > > From: Alexander Duyck > > > > > > In order to support page reporting it will be necessary to store and > > > retrieve the migratetype of a page. To enable that I am moving the set and > > > get operations for pcppage_migratetype into the mm/internal.h header so > > > that they can be used outside of the page_alloc.c file. > > > > Please describe who is the user and why does it needs this interface. > > This is really important because migratetype is an MM internal thing and > > external users shouldn't really care about it at all. We really do not > > want a random code to call those, especially the set_pcppage_migratetype. > > I was using it to store the migratetype of the page so that I could > find the boundary list that contained the reported page as the array > is indexed based on page order and migratetype. However on further > discussion I am thinking I may just use page->index directly to index > into the boundary array. Doing that I should be able to get a very > slight improvement in lookup time since I am not having to pull order > and migratetype and then compute the index based on that. In addition > it becomes much more clear as to what is going on, and if needed I > could add debug checks to verify the page is "Reported" and that the > "Buddy" page type is set. Be careful though. A free page belongs to the page allocator and it is free to reuse any fields for its purpose so using any of them nilly willy is no go. If you need to stuff something like that then there better be an api the allocator is aware of. My main objection is the abuse migrate type. There might be other ways to express what you need. Please make sure you clearly define that though. -- Michal Hocko SUSE Labs 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=-2.5 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_SANE_1 autolearn=no 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 60808C49ED7 for ; Tue, 10 Sep 2019 17:46:09 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 2E65621881 for ; Tue, 10 Sep 2019 17:46:09 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="l4TSp8h1" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2E65621881 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=I/e2bvHMeAgyuqVS1L6xmxl1Yv2hQDb7nhaj3Lw2Pkc=; b=l4TSp8h1erIb1H HrOBle9aH0CHd+gVIsNgL85chywji6MwmVw463YpYL4C6ExABSQGZwcl9be/lFcKdXcSSqlc1KIG8 oz+YqxogfwZHUAz3sGeJHn8gMxnvgGEEl+8/bL5KZ5p+B7HgEaIOrgTVp9EJDMNA3tzxXxE9sDMSm fV+HRFX23vYIgTlIrW/5uBqrFgHgprsZpLj/uYHNuW+WYo4rgSv0JI6OgxIjm2UxkCxjan4+UFjRm ZsZos+xm0fvDvwOvp74AS3caECBohBmUTjLPnUF7HXS1AMovop5PsSxhunqPmb0YO+mOAOlE4r6/B R7zathI3WGtro+Fi1LgQ==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92 #3 (Red Hat Linux)) id 1i7kDL-0006Z2-KW; Tue, 10 Sep 2019 17:46:03 +0000 Received: from mx2.suse.de ([195.135.220.15] helo=mx1.suse.de) by bombadil.infradead.org with esmtps (Exim 4.92 #3 (Red Hat Linux)) id 1i7kDI-0006Xn-4z for linux-arm-kernel@lists.infradead.org; Tue, 10 Sep 2019 17:46:01 +0000 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 E89D9AD17; Tue, 10 Sep 2019 17:45:54 +0000 (UTC) Date: Tue, 10 Sep 2019 19:45:53 +0200 From: Michal Hocko To: Alexander Duyck Subject: Re: [PATCH v9 3/8] mm: Move set/get_pcppage_migratetype to mmzone.h Message-ID: <20190910174553.GC4023@dhcp22.suse.cz> References: <20190907172225.10910.34302.stgit@localhost.localdomain> <20190907172528.10910.37051.stgit@localhost.localdomain> <20190910122313.GW2063@dhcp22.suse.cz> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190910_104600_334583_2CB14448 X-CRM114-Status: GOOD ( 19.93 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Yang Zhang , Pankaj Gupta , kvm list , David Hildenbrand , Catalin Marinas , lcapitulino@redhat.com, linux-mm , Alexander Duyck , will@kernel.org, Andrea Arcangeli , virtio-dev@lists.oasis-open.org, "Michael S. Tsirkin" , Matthew Wilcox , "Wang, Wei W" , ying.huang@intel.com, Rik van Riel , Konrad Rzeszutek Wilk , Dan Williams , linux-arm-kernel@lists.infradead.org, Oscar Salvador , Nitesh Narayan Lal , Dave Hansen , LKML , Paolo Bonzini , Andrew Morton , Fengguang Wu , "Kirill A. Shutemov" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue 10-09-19 07:46:50, Alexander Duyck wrote: > On Tue, Sep 10, 2019 at 5:23 AM Michal Hocko wrote: > > > > On Sat 07-09-19 10:25:28, Alexander Duyck wrote: > > > From: Alexander Duyck > > > > > > In order to support page reporting it will be necessary to store and > > > retrieve the migratetype of a page. To enable that I am moving the set and > > > get operations for pcppage_migratetype into the mm/internal.h header so > > > that they can be used outside of the page_alloc.c file. > > > > Please describe who is the user and why does it needs this interface. > > This is really important because migratetype is an MM internal thing and > > external users shouldn't really care about it at all. We really do not > > want a random code to call those, especially the set_pcppage_migratetype. > > I was using it to store the migratetype of the page so that I could > find the boundary list that contained the reported page as the array > is indexed based on page order and migratetype. However on further > discussion I am thinking I may just use page->index directly to index > into the boundary array. Doing that I should be able to get a very > slight improvement in lookup time since I am not having to pull order > and migratetype and then compute the index based on that. In addition > it becomes much more clear as to what is going on, and if needed I > could add debug checks to verify the page is "Reported" and that the > "Buddy" page type is set. Be careful though. A free page belongs to the page allocator and it is free to reuse any fields for its purpose so using any of them nilly willy is no go. If you need to stuff something like that then there better be an api the allocator is aware of. My main objection is the abuse migrate type. There might be other ways to express what you need. Please make sure you clearly define that though. -- Michal Hocko SUSE Labs _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel