Re: [PATCH v9 0/8] stg mail -e --version=v9 \

From: David Hildenbrand <david@redhat.com>
To: Michal Hocko <mhocko@kernel.org>,
	Alexander Duyck <alexander.h.duyck@linux.intel.com>
Cc: Yang Zhang <yang.zhang.wz@gmail.com>,
	Pankaj Gupta <pagupta@redhat.com>, kvm list <kvm@vger.kernel.org>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Alexander Duyck <alexander.duyck@gmail.com>,
	lcapitulino@redhat.com, linux-mm <linux-mm@kvack.org>,
	will@kernel.org, Andrea Arcangeli <aarcange@redhat.com>,
	virtio-dev@lists.oasis-open.org, Rik van Riel <riel@surriel.com>,
	Matthew Wilcox <willy@infradead.org>,
	"Wang, Wei W" <wei.w.wang@intel.com>,
	ying.huang@intel.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Dan Williams <dan.j.williams@intel.com>,
	linux-arm-kernel@lists.infradead.org,
	Oscar Salvador <osalvador@suse.de>,
	Nitesh Narayan Lal <nitesh@redhat.com>,
	Dave Hansen <dave.hansen@intel.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Fengguang Wu <fengguang.wu@intel.com>,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
Subject: Re: [PATCH v9 0/8] stg mail -e --version=v9 \
Date: Wed, 11 Sep 2019 13:47:30 +0200	[thread overview]
Message-ID: <9ac38890-be04-036e-0d6c-ea54e35a20db@redhat.com> (raw)
In-Reply-To: <20190911113619.GP4023@dhcp22.suse.cz>

On 11.09.19 13:36, Michal Hocko wrote:
> 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
> 

FWIW, Nitesh was looking into another approach [1], whereby the metadata
is stored outside of the buddy (unreported pages are tracked in a
bitmap). There are some limitations to this approach (esp., sparse zones
might waste memory (1bit per 2MB), memory hot(un)plug not supported yet
completely, scanning of the bitmap necessary). OTOH, the core buddy
modifications are minimized.

[1] https://lkml.org/lkml/2019/8/12/593

-- 

Thanks,

David / dhildenb

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel