On Tue, Apr 13, 2021 at 03:40:18PM +0200, Michal Hocko wrote:
> > + /*
> > +* Call __prep_new_huge_page() to construct the hugetlb page,
> > and
> > +* enqueue it then to place it in the freelists. After this,
> > +* counters are back on track. Free
On Wed, Apr 14, 2021 at 02:26:21PM +0200, David Hildenbrand wrote:
> > +static inline int isolate_or_dissolve_huge_page(struct page *page)
> > +{
> > + return -ENOMEM;
>
> Without CONFIG_HUGETLB_PAGE, there is no way someone could possible pass in
> something valid. Although it doesn't matter
+static inline int isolate_or_dissolve_huge_page(struct page *page)
+{
+ return -ENOMEM;
Without CONFIG_HUGETLB_PAGE, there is no way someone could possible pass
in something valid. Although it doesn't matter too much, -EINVAL or
similar sounds a bit better.
+}
+
static inline
On Tue, Apr 13, 2021 at 03:29:02PM -0700, Mike Kravetz wrote:
> > spin_lock_irq(hugetlb_lock)
> > 1) update_and_free_page
> >PageHuge() == F
> >__free_pages()
> > 2) enqueue_huge_page
> >SetPageHugeFreed()
> > spin_unlock(_lock)
>
> Very small nit, the above should
On 4/13/21 3:47 AM, Oscar Salvador wrote:
> alloc_contig_range will fail if it ever sees a HugeTLB page within the
> range we are trying to allocate, even when that page is free and can be
> easily reallocated.
> This has proved to be problematic for some users of alloc_contic_range,
> e.g: CMA
On Tue 13-04-21 12:47:45, Oscar Salvador wrote:
> alloc_contig_range will fail if it ever sees a HugeTLB page within the
> range we are trying to allocate, even when that page is free and can be
> easily reallocated.
> This has proved to be problematic for some users of alloc_contic_range,
> e.g:
alloc_contig_range will fail if it ever sees a HugeTLB page within the
range we are trying to allocate, even when that page is free and can be
easily reallocated.
This has proved to be problematic for some users of alloc_contic_range,
e.g: CMA and virtio-mem, where those would fail the call even
7 matches
Mail list logo
