On 25.06.19 19:00, Alexander Duyck wrote: > On Tue, Jun 25, 2019 at 7:10 AM Dave Hansen <dave.hansen@xxxxxxxxx> wrote: >> >> On 6/25/19 12:42 AM, David Hildenbrand wrote: >>> On 20.06.19 00:32, Alexander Duyck wrote: >>> I still *detest* the terminology, sorry. Can't you come up with a >>> simpler terminology that makes more sense in the context of operating >>> systems and pages we want to hint to the hypervisor? (that is the only >>> use case you are using it for so far) >> >> It's a wee bit too cute for my taste as well. I could probably live >> with it in the data structures, but having it show up out in places like >> Kconfig and filenames goes too far. >> >> For instance, someone seeing memory_aeration.c will have no concept >> what's in the file. Could we call it something like memory_paravirt.c? >> Or even mm/paravirt.c. > > Well I couldn't come up with a better explanation of what this was > doing, also I wanted to avoid mentioning hinting specifically because > there have already been a few series that have been committed upstream > that reference this for slightly different purposes such as the one by > Wei Wang that was doing free memory tracking for migration purposes, > https://lkml.org/lkml/2018/7/10/211. That one we referred to rather as "free page reporting". > > Basically what we are doing is inflating the memory size we can report > by inserting voids into the free memory areas. In my mind that matches > up very well with what "aeration" is. It is similar to balloon in > functionality, however instead of inflating the balloon we are > inflating the free_list for higher order free areas by creating voids > where the madvised pages were. > >> Could you talk for a minute about why the straightforward naming like >> "hinted/unhinted" wasn't used? Is there something else we could ever >> use this infrastructure for that is not related to paravirtualized free >> page hinting? > > I was hoping there might be something in the future that could use the > infrastructure if it needed to go through and sort out used versus > unused memory. The way things are designed right now for instance > there is only really a define that is limiting the lowest order pages > that are processed. So if we wanted to use this for another purpose we > could replace the AERATOR_MIN_ORDER define with something that is > specific to that use case. I'd still vote to call this "hinting" in some form. Whenever a new use case eventually pops up, we could generalize this approach. But well, that's just my opinion :) -- Thanks, David / dhildenb
