On Wed, Nov 14, 2018 at 11:49:15PM +0100, David Hildenbrand wrote: > On 14.11.18 23:23, Matthew Wilcox wrote: > > On Wed, Nov 14, 2018 at 10:17:00PM +0100, David Hildenbrand wrote: > >> Rename PG_balloon to PG_offline. This is an indicator that the page is > >> logically offline, the content stale and that it should not be touched > >> (e.g. a hypervisor would have to allocate backing storage in order for the > >> guest to dump an unused page). We can then e.g. exclude such pages from > >> dumps. > >> > >> In following patches, we will make use of this bit also in other balloon > >> drivers. While at it, document PGTABLE. > > > > Thank you for documenting PGTABLE. I didn't realise I also had this > > document to update when I added PGTABLE. > > Thank you for looking into this :) > > > > >> +++ b/Documentation/admin-guide/mm/pagemap.rst > >> @@ -78,6 +78,8 @@ number of times a page is mapped. > >> 23. BALLOON > >> 24. ZERO_PAGE > >> 25. IDLE > >> + 26. PGTABLE > >> + 27. OFFLINE > > > > So the offline *user* bit is new ... even though the *kernel* bit > > just renames the balloon bit. I'm not sure how I feel about this. > > I'm going to think about it some more. Could you share your decision > > process with us? > > BALLOON was/is documented as > > "23 - BALLOON > balloon compaction page > " > > and only includes all virtio-ballon pages after the non-lru migration > feature has been implemented for ballooned pages. Since then, this flag > does basically no longer stands for what it actually was supposed to do. Perhaps I missing something, but how the user should interpret "23" when he reads /proc/kpageflags? > To not break uapi I decided to not rename it but instead to add a new flag. I've got a feeling that uapi was anyway changed for the BALLON flag meaning. > > > > I have no objection to renaming the balloon bit inside the kernel; I > > think that's a wise idea. I'm just not sure whether we should rename > > the user balloon bit rather than adding a new bit. > > > > Can we rename without breaking uapi? > > -- > > Thanks, > > David / dhildenb > -- Sincerely yours, Mike. _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
