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, 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 7AC0FC49ED6 for ; Wed, 11 Sep 2019 11:36:24 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 4F5ED2081B for ; Wed, 11 Sep 2019 11:36:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1568201784; bh=WSBYT//F0n9vJ9lXGcy6U6Y+OjPG3w/fS5tHh2llcJ8=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=CAW8XHTyxdNRPuuYD2OHj8n3CMkVPmUd5HWhhnbDqn2UlBHtqCZYP1OX/5SpRblZF akAaeDb4QTNqJFRGvq3KE4/dlUkjpoYPelpIzRCbSRS2ts0wbCbVOZwke001WoMsrh IJ83dyFDcKEPN7zbE4b9FYqCjelIAPz0ReJUBVOQ= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727697AbfIKLgX (ORCPT ); Wed, 11 Sep 2019 07:36:23 -0400 Received: from mx2.suse.de ([195.135.220.15]:51928 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727302AbfIKLgX (ORCPT ); Wed, 11 Sep 2019 07:36:23 -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 038DEAD08; Wed, 11 Sep 2019 11:36:20 +0000 (UTC) Date: Wed, 11 Sep 2019 13:36:19 +0200 From: Michal Hocko To: Alexander Duyck Cc: Alexander Duyck , 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 , "Kirill A. Shutemov" Subject: Re: [PATCH v9 0/8] stg mail -e --version=v9 \ Message-ID: <20190911113619.GP4023@dhcp22.suse.cz> References: <20190907172225.10910.34302.stgit@localhost.localdomain> <20190910124209.GY2063@dhcp22.suse.cz> <20190910144713.GF2063@dhcp22.suse.cz> <20190910175213.GD4023@dhcp22.suse.cz> <1d7de9f9f4074f67c567dbb4cc1497503d739e30.camel@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1d7de9f9f4074f67c567dbb4cc1497503d739e30.camel@linux.intel.com> 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 14:23:40, Alexander Duyck wrote: [...] > We don't put any limitations on the allocator other then that it needs to > clean up the metadata on allocation, and that it cannot allocate a page > that is in the process of being reported since we pulled it from the > free_list. If the page is a "Reported" page then it decrements the > reported_pages count for the free_area and makes sure the page doesn't > exist in the "Boundary" array pointer value, if it does it moves the > "Boundary" since it is pulling the page. This is still a non-trivial limitation on the page allocation from an external code IMHO. I cannot give any explicit reason why an ordering on the free list might matter (well except for page shuffling which uses it to make physical memory pattern allocation more random) but the architecture seems hacky and dubious to be honest. It shoulds like the whole interface has been developed around a very particular and single purpose optimization. I remember that there was an attempt to report free memory that provided a callback mechanism [1], which was much less intrusive to the internals of the allocator yet it should provide a similar functionality. Did you see that approach? How does this compares to it? Or am I completely off when comparing them? [1] mostly likely not the latest version of the patchset http://lkml.kernel.org/r/1502940416-42944-5-git-send-email-wei.w.wang@intel.com -- 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,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 597EAECDE20 for ; Wed, 11 Sep 2019 11:37:04 +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 30FEA2081B for ; Wed, 11 Sep 2019 11:37:04 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="U1r5OTd3" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 30FEA2081B 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=CQn9K8yyu2I2B7B3m+dDkLJfwo61WGgMTMr61XgfAd4=; b=U1r5OTd35kX6RD EgapI0j2g/T4KN6QHViaPB/UMIqxBQIT3calnjfkSG5Y2Js0/tJZ64s3kCIKBjG65mBNvtvfDUhLF wQvLtZLdUEgcFWsF3nnNNM0M1+5tpg9U+MZdWKEnwhb761dvDmlX2oFJ1SOT9iAeJQQkPXOkwh0W8 HC2Q2j1zfW2N8rAIESutOZWLw0Y2FKiuYnEuC08rPrQmO6oG6f5VKKEh+htu34UCb1pdGaQiOoMly ypIuoZ/cQx546wKu+S2cM7/Or/FeJ4lpDQUnoUSi7PWjAFGK70GCGfEZiacLlJZoKBBmm39VohKuy UYYnxSk3kRv14sDpY0fA==; 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 1i80vV-0005QS-Bw; Wed, 11 Sep 2019 11:36:47 +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 1i80v9-0005Nr-6F for linux-arm-kernel@lists.infradead.org; Wed, 11 Sep 2019 11:36:34 +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 038DEAD08; Wed, 11 Sep 2019 11:36:20 +0000 (UTC) Date: Wed, 11 Sep 2019 13:36:19 +0200 From: Michal Hocko To: Alexander Duyck Subject: Re: [PATCH v9 0/8] stg mail -e --version=v9 \ Message-ID: <20190911113619.GP4023@dhcp22.suse.cz> References: <20190907172225.10910.34302.stgit@localhost.localdomain> <20190910124209.GY2063@dhcp22.suse.cz> <20190910144713.GF2063@dhcp22.suse.cz> <20190910175213.GD4023@dhcp22.suse.cz> <1d7de9f9f4074f67c567dbb4cc1497503d739e30.camel@linux.intel.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1d7de9f9f4074f67c567dbb4cc1497503d739e30.camel@linux.intel.com> 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-20190911_043623_758598_72CC7AA8 X-CRM114-Status: GOOD ( 13.75 ) 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 , Alexander Duyck , lcapitulino@redhat.com, linux-mm , 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 , Dan Williams , linux-arm-kernel@lists.infradead.org, Oscar Salvador , Nitesh Narayan Lal , Konrad Rzeszutek Wilk , 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 14:23:40, Alexander Duyck wrote: [...] > We don't put any limitations on the allocator other then that it needs to > clean up the metadata on allocation, and that it cannot allocate a page > that is in the process of being reported since we pulled it from the > free_list. If the page is a "Reported" page then it decrements the > reported_pages count for the free_area and makes sure the page doesn't > exist in the "Boundary" array pointer value, if it does it moves the > "Boundary" since it is pulling the page. This is still a non-trivial limitation on the page allocation from an external code IMHO. I cannot give any explicit reason why an ordering on the free list might matter (well except for page shuffling which uses it to make physical memory pattern allocation more random) but the architecture seems hacky and dubious to be honest. It shoulds like the whole interface has been developed around a very particular and single purpose optimization. I remember that there was an attempt to report free memory that provided a callback mechanism [1], which was much less intrusive to the internals of the allocator yet it should provide a similar functionality. Did you see that approach? How does this compares to it? Or am I completely off when comparing them? [1] mostly likely not the latest version of the patchset http://lkml.kernel.org/r/1502940416-42944-5-git-send-email-wei.w.wang@intel.com -- Michal Hocko SUSE Labs _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel