From: Dave Hansen <dave.hansen@intel.com> To: Alexander Duyck <alexander.duyck@gmail.com>, nitesh@redhat.com, kvm@vger.kernel.org, david@redhat.com, mst@redhat.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, akpm@linux-foundation.org Cc: yang.zhang.wz@gmail.com, pagupta@redhat.com, riel@surriel.com, konrad.wilk@oracle.com, lcapitulino@redhat.com, wei.w.wang@intel.com, aarcange@redhat.com, pbonzini@redhat.com, dan.j.williams@intel.com, alexander.h.duyck@linux.intel.com Subject: Re: [PATCH v1 4/6] mm: Introduce "aerated" pages Date: Tue, 25 Jun 2019 12:45:44 -0700 Message-ID: <a147b569-9f1b-a1be-e019-0059c654892d@intel.com> (raw) In-Reply-To: <20190619223323.1231.86906.stgit@localhost.localdomain> > +static inline void set_page_aerated(struct page *page, > + struct zone *zone, > + unsigned int order, > + int migratetype) > +{ > +#ifdef CONFIG_AERATION > + /* update areated page accounting */ > + zone->free_area[order].nr_free_aerated++; > + > + /* record migratetype and flag page as aerated */ > + set_pcppage_migratetype(page, migratetype); > + __SetPageAerated(page); > +#endif > +} Please don't refer to code before you introduce it, even if you #ifdef it. I went looking back in the series for the PageAerated() definition, but didn't think to look forward. Also, it doesn't make any sense to me that you would need to set the migratetype here. Isn't it set earlier in the allocator? Also, when can this function be called? There's obviously some locking in place because of the __Set, but what are they? > +static inline void clear_page_aerated(struct page *page, > + struct zone *zone, > + struct free_area *area) > +{ > +#ifdef CONFIG_AERATION > + if (likely(!PageAerated(page))) > + return; Logically, why would you ever clear_page_aerated() on a page that's not aerated? Comments needed. BTW, I already hate typing aerated. :) > + __ClearPageAerated(page); > + area->nr_free_aerated--; > +#endif > +} More non-atomic flag clears. Still no comments. > @@ -787,10 +790,10 @@ static inline void add_to_free_area(struct page *page, struct zone *zone, > static inline void add_to_free_area_tail(struct page *page, struct zone *zone, > unsigned int order, int migratetype) > { > - struct free_area *area = &zone->free_area[order]; > + struct list_head *tail = aerator_get_tail(zone, order, migratetype); There is no logical change in this patch from this line. That's unfortunate because I can't see the change in logic that's presumably coming. You'll presumably change aerator_get_tail(), but then I'll have to remember that this line is here and come back to it from a later patch. If it *doesn't* change behavior, it has no business being calle aerator_...(). This series seems rather suboptimal for reviewing. > - list_add_tail(&page->lru, &area->free_list[migratetype]); > - area->nr_free++; > + list_add_tail(&page->lru, tail); > + zone->free_area[order].nr_free++; > } > > /* Used for pages which are on another list */ > @@ -799,6 +802,8 @@ static inline void move_to_free_area(struct page *page, struct zone *zone, > { > struct free_area *area = &zone->free_area[order]; > > + clear_page_aerated(page, zone, area); > + > list_move(&page->lru, &area->free_list[migratetype]); > } It's not immediately clear to me why moving a page should clear aeration. A comment would help make it clear. > @@ -868,10 +869,11 @@ static inline struct capture_control *task_capc(struct zone *zone) > static inline void __free_one_page(struct page *page, > unsigned long pfn, > struct zone *zone, unsigned int order, > - int migratetype) > + int migratetype, bool aerated) > { > struct capture_control *capc = task_capc(zone); > unsigned long uninitialized_var(buddy_pfn); > + bool fully_aerated = aerated; > unsigned long combined_pfn; > unsigned int max_order; > struct page *buddy; > @@ -902,6 +904,11 @@ static inline void __free_one_page(struct page *page, > goto done_merging; > if (!page_is_buddy(page, buddy, order)) > goto done_merging; > + > + /* assume buddy is not aerated */ > + if (aerated) > + fully_aerated = false; So, "full" vs. "partial" is with respect to high-order pages? Why not just check the page flag on the buddy? > /* > * Our buddy is free or it is CONFIG_DEBUG_PAGEALLOC guard page, > * merge with it and move up one order. > @@ -943,11 +950,17 @@ static inline void __free_one_page(struct page *page, > done_merging: > set_page_order(page, order); > > - if (buddy_merge_likely(pfn, buddy_pfn, page, order) || > + if (aerated || > + buddy_merge_likely(pfn, buddy_pfn, page, order) || > is_shuffle_tail_page(order)) > add_to_free_area_tail(page, zone, order, migratetype); > else > add_to_free_area(page, zone, order, migratetype); Aerated pages always go to the tail? Ahh, so they don't get consumed quickly and have to be undone? Comments, please. > + if (fully_aerated) > + set_page_aerated(page, zone, order, migratetype); > + else > + aerator_notify_free(zone, order); > } What is this notifying for? It's not like this is some opaque registration interface. What does this *do*? > @@ -2127,6 +2140,77 @@ struct page *__rmqueue_smallest(struct zone *zone, unsigned int order, > return NULL; > } > > +#ifdef CONFIG_AERATION > +/** > + * get_aeration_page - Provide a "raw" page for aeration by the aerator > + * @zone: Zone to draw pages from > + * @order: Order to draw pages from > + * @migratetype: Migratetype to draw pages from FWIW, kerneldoc is a waste of bytes here. Please use it sparingly. > + * This function will obtain a page from above the boundary. As a result > + * we can guarantee the page has not been aerated. This is the first mention of a boundary. That's not good since I have no idea at this point what the boundary is for or between. > + * The page will have the migrate type and order stored in the page > + * metadata. > + * > + * Return: page pointer if raw page found, otherwise NULL > + */ > +struct page *get_aeration_page(struct zone *zone, unsigned int order, > + int migratetype) > +{ > + struct free_area *area = &(zone->free_area[order]); > + struct list_head *list = &area->free_list[migratetype]; > + struct page *page; > + > + /* Find a page of the appropriate size in the preferred list */ I don't get the size comment. Hasn't this already been given an order? > + page = list_last_entry(aerator_get_tail(zone, order, migratetype), > + struct page, lru); > + list_for_each_entry_from_reverse(page, list, lru) { > + if (PageAerated(page)) { > + page = list_first_entry(list, struct page, lru); > + if (PageAerated(page)) > + break; > + } This confuses me. It looks for a page, then goes to the next page and checks again? Why check twice? Why is a function looking for an aerated page that finds *two* pages returning NULL? I'm stumped. > + del_page_from_free_area(page, zone, order); > + > + /* record migratetype and order within page */ > + set_pcppage_migratetype(page, migratetype); > + set_page_private(page, order); > + __mod_zone_freepage_state(zone, -(1 << order), migratetype); > + > + return page; > + } > + > + return NULL; > +} Oh, so this is trying to find a page _for_ aerating. "get_aeration_page()" does not convey that. Can that improved? get_page_for_aeration()? Rather than talk about boundaries, wouldn't a better description have been: Similar to allocation, this function removes a page from the free lists. However, it only removes unaerated pages. > +/** > + * put_aeration_page - Return a now-aerated "raw" page back where we got it > + * @zone: Zone to return pages to > + * @page: Previously "raw" page that can now be returned after aeration > + * > + * This function will pull the migratetype and order information out > + * of the page and attempt to return it where it found it. > + */ > +void put_aeration_page(struct zone *zone, struct page *page) > +{ > + unsigned int order, mt; > + unsigned long pfn; > + > + mt = get_pcppage_migratetype(page); > + pfn = page_to_pfn(page); > + > + if (unlikely(has_isolate_pageblock(zone) || is_migrate_isolate(mt))) > + mt = get_pfnblock_migratetype(page, pfn); > + > + order = page_private(page); > + set_page_private(page, 0); > + > + __free_one_page(page, pfn, zone, order, mt, true); > +} > +#endif /* CONFIG_AERATION */ Yikes. This seems to have glossed over some pretty big aspects here. Pages which are being aerated are not free. Pages which are freed are diverted to be aerated before becoming free. Right? That sounds like two really important things to add to a changelog. > /* > * This array describes the order lists are fallen back to when > * the free lists for the desirable migrate type are depleted > @@ -5929,9 +6013,12 @@ void __ref memmap_init_zone_device(struct zone *zone, > static void __meminit zone_init_free_lists(struct zone *zone) > { > unsigned int order, t; > - for_each_migratetype_order(order, t) { > + for_each_migratetype_order(order, t) > INIT_LIST_HEAD(&zone->free_area[order].free_list[t]); > + > + for (order = MAX_ORDER; order--; ) { > zone->free_area[order].nr_free = 0; > + zone->free_area[order].nr_free_aerated = 0; > } > } > >
next prev parent reply index Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-06-19 22:32 [PATCH v1 0/6] mm / virtio: Provide support for paravirtual waste page treatment Alexander Duyck 2019-06-19 22:33 ` [PATCH v1 1/6] mm: Adjust shuffle code to allow for future coalescing Alexander Duyck 2019-06-25 7:55 ` David Hildenbrand 2019-06-28 19:49 ` Alexander Duyck 2019-06-25 18:25 ` Dave Hansen 2019-06-25 18:26 ` Dave Hansen 2019-06-19 22:33 ` [PATCH v1 2/6] mm: Move set/get_pcppage_migratetype to mmzone.h Alexander Duyck 2019-06-25 18:28 ` Dave Hansen 2019-06-28 19:55 ` Alexander Duyck 2019-06-19 22:33 ` [PATCH v1 3/6] mm: Use zone and order instead of free area in free_list manipulators Alexander Duyck 2019-06-25 18:36 ` Dave Hansen 2019-06-19 22:33 ` [PATCH v1 4/6] mm: Introduce "aerated" pages Alexander Duyck 2019-06-25 19:45 ` Dave Hansen [this message] 2019-07-08 17:32 ` Alexander Duyck 2019-06-19 22:33 ` [PATCH v1 5/6] mm: Add logic for separating "aerated" pages from "raw" pages Alexander Duyck 2019-06-25 20:24 ` Dave Hansen 2019-07-08 19:02 ` Alexander Duyck 2019-07-08 19:36 ` Dave Hansen 2019-07-08 22:02 ` Alexander Duyck 2019-06-19 22:33 ` [PATCH v1 6/6] virtio-balloon: Add support for aerating memory via hinting Alexander Duyck 2019-07-16 9:55 ` Michael S. Tsirkin 2019-07-16 14:00 ` Dave Hansen 2019-07-16 14:12 ` David Hildenbrand 2019-07-16 14:17 ` David Hildenbrand 2019-07-16 15:04 ` Michael S. Tsirkin 2019-07-16 14:41 ` Dave Hansen 2019-07-16 15:01 ` Wang, Wei W 2019-07-16 16:12 ` Michael S. Tsirkin 2019-07-16 15:02 ` David Hildenbrand 2019-07-16 15:37 ` Alexander Duyck 2019-07-16 16:07 ` Michael S. Tsirkin 2019-07-16 16:54 ` Alexander Duyck 2019-07-16 17:41 ` Michael S. Tsirkin 2019-07-16 21:06 ` Alexander Duyck 2019-07-17 10:28 ` Michael S. Tsirkin 2019-07-17 16:43 ` Alexander Duyck 2019-07-18 5:13 ` Michael S. Tsirkin 2019-07-18 15:34 ` Alexander Duyck 2019-07-18 16:03 ` Nitesh Narayan Lal 2019-07-18 20:27 ` Michael S. Tsirkin 2019-07-18 16:07 ` Michael S. Tsirkin 2019-07-18 20:29 ` Alexander Duyck 2019-07-18 20:37 ` Michael S. Tsirkin 2019-07-18 20:54 ` Alexander Duyck 2019-07-18 20:24 ` Michael S. Tsirkin 2019-07-18 20:34 ` Alexander Duyck 2019-07-18 20:48 ` Michael S. Tsirkin 2019-07-18 21:09 ` Alexander Duyck 2019-06-19 22:37 ` [PATCH v1 QEMU] QEMU: Provide a interface for hinting based off of the balloon infrastructure Alexander Duyck 2019-06-25 7:42 ` [PATCH v1 0/6] mm / virtio: Provide support for paravirtual waste page treatment David Hildenbrand 2019-06-25 14:10 ` Dave Hansen 2019-06-25 17:00 ` Alexander Duyck 2019-06-25 18:12 ` David Hildenbrand 2019-06-25 18:22 ` Dave Hansen 2019-07-15 9:41 ` David Hildenbrand 2019-07-15 14:57 ` Alexander Duyck 2019-06-25 16:09 ` Alexander Duyck 2019-06-26 9:01 ` Christophe de Dinechin 2019-06-26 9:12 ` David Hildenbrand
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=a147b569-9f1b-a1be-e019-0059c654892d@intel.com \ --to=dave.hansen@intel.com \ --cc=aarcange@redhat.com \ --cc=akpm@linux-foundation.org \ --cc=alexander.duyck@gmail.com \ --cc=alexander.h.duyck@linux.intel.com \ --cc=dan.j.williams@intel.com \ --cc=david@redhat.com \ --cc=konrad.wilk@oracle.com \ --cc=kvm@vger.kernel.org \ --cc=lcapitulino@redhat.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=mst@redhat.com \ --cc=nitesh@redhat.com \ --cc=pagupta@redhat.com \ --cc=pbonzini@redhat.com \ --cc=riel@surriel.com \ --cc=wei.w.wang@intel.com \ --cc=yang.zhang.wz@gmail.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
KVM Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/kvm/0 kvm/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 kvm kvm/ https://lore.kernel.org/kvm \ kvm@vger.kernel.org public-inbox-index kvm Example config snippet for mirrors Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kernel.vger.kvm AGPL code for this site: git clone https://public-inbox.org/public-inbox.git