On 25.07.19 22:37, Alexander Duyck wrote: > On Thu, 2019-07-25 at 20:32 +0200, David Hildenbrand wrote: >> On 25.07.19 19:38, Alexander Duyck wrote: >>> On Thu, 2019-07-25 at 18:48 +0200, David Hildenbrand wrote: >>>> On 25.07.19 17:59, Alexander Duyck wrote: >>>>> On Thu, Jul 25, 2019 at 1:53 AM David Hildenbrand <david@xxxxxxxxxx> wrote: >>>>>> On 24.07.19 19:03, Alexander Duyck wrote: >>>>>>> From: Alexander Duyck <alexander.h.duyck@xxxxxxxxxxxxxxx> >>> >>> <snip> >>> >>>>>> Can't we reuse one of the traditional page flags for that, not used >>>>>> along with buddy pages? E.g., PG_dirty: Pages that were not hinted yet >>>>>> are dirty. >>>>> >>>>> Reusing something like the dirty bit would just be confusing in my >>>>> opinion. In addition it looks like Xen has also re-purposed PG_dirty >>>>> already for another purpose. >>>> >>>> You brought up waste page management. A dirty bit for unprocessed pages >>>> fits perfectly in this context. Regarding XEN, as long as it's not used >>>> along with buddy pages, no issue. >>> >>> I would rather not have to dirty all pages that aren't hinted. That starts >>> to get too invasive. Ideally we only modify pages if we are hinting on >>> them. That is why I said I didn't like the use of a dirty bit. What we >>> want is more of a "guaranteed clean" bit. >> >> Not sure if that is too invasive, but fair enough. >> >>>> FWIW, I don't even thing PG_offline matches to what you are using it >>>> here for. The pages are not logically offline. They were simply buddy >>>> pages that were hinted. (I'd even prefer a separate page type for that >>>> instead - if we cannot simply reuse one of the other flags) >>>> >>>> "Offline pages" that are not actually offline in the context of the >>>> buddy is way more confusing. >>> >>> Right now offline and hinted are essentially the same thing since the >>> effect is identical. >> >> No they are not the same thing. Regarding virtio-balloon: You are free >> to reuse any hinted pages immediate. Offline pages (a.k.a. inflated) you >> might not generally reuse before deflating. > > Okay, so it sounds like your perspective is a bit different than mine. I > was thinking of it from the perspective of the host OS where in either > case the guest has set the page as MADV_DONTNEED. You are looking at it > from the guest perspective where Offline means the guest cannot use it. > >>> There may be cases in the future where that is not the case, but with the >>> current patch set they both result in the pages being evicted from the >>> guest. >>> >>>>> If anything I could probably look at seeing if the PG_private flags >>>>> are available when a page is in the buddy allocator which I suspect >>>>> they probably are since the only users I currently see appear to be >>>>> SLOB and compound pages. Either that or maybe something like PG_head >>>>> might make sense since once we start allocating them we are popping >>>>> the head off of the boundary list. >>>> >>>> Would also be fine with me. >>> >>> Actually I may have found an even better bit if we are going with the >>> "reporting" name. I could probably use "PG_uptodate" since it looks like >>> most of its uses are related to filesystems. I will wait till I hear from >>> Matthew on what bits would be available for use before I update things. >> >> Also fine with me. In the optimal case we (in my opinion) >> a) Don't reuse PG_offline >> b) Don't use another page type > > That is fine. I just need to determine the exact flag to use then. I'll do > some more research and wait to see if anyone else from MM comunity has > input or suggestions on the page flag to be used. From what I can tell it > looks like there are a bunch of flag bits that are unused as far as the > buddy pages are concerned so I should have a few to choose from. Right, and I would favor that - at least less hacking with the kexec/kdump interface :) You can then go ahead and add PG_hinted or PG_reported = PG_*younameit* and properly document how it is being used along with PageBuddy() only. -- Thanks, David / dhildenb
