On Wed, Dec 11, 2024 at 11:27:39AM +0100, David Hildenbrand wrote: > > > > > > > OK so I think we're (probably?) now agreed, I will submit a patch shortly > > that: > > > > a. puts everything in MEMORY MAPPING > > b. Drops mm/madvise.c, mm/msync.c from the list > > c. I commit to moving things out of the various files that truly belongs > > elsewhere > > > I mean there's stuff that's weirdly used for page table moving in > mremap.c > > that should probably live in memory.c as well for instance. > > Yes, and hopefully we can clearly frame what MEMORY MAPPING is supposed to > contain. I tried to tackle it with "/proc/self/maps output", but that's > probably not the complete story. I think any definition will end up a little fuzzy. For me it's anything relating to mapping memory and changing its attributes. I quite like the 'anything that affects /proc/self/maps output' but of course you can find exceptions to all these rules... I think we just have to live with a bit of vagueness unfortunately. But we can definitely do future work on moving things around to make this clearer. I think there's more benefit to moving stuff around than some strict adherence to a sense of X belongs in file y etc., because it also encourages de-duplication and prevents unrelated logic sitting in a file where it might be neglected. Anyway one for the new year :) > > For example, maybe mbind() should, for example, at some point be separated > out into into mbind.c (making use of mempolicy.c functionality?) and covered > there as well? I really don't know, maybe it's not one of the > mmap/munmap/mprotect/mremap/mseal/mlock gang after all. I sort of feel it's ok to have that in mempolicy.c with other NUMA related syscalls, it's still grouped by syscall pretty much there. We do have weirdness with random things that don't seem to belong sitting in random files though, vma_migratable() being there is weird for instance. Anyway, one thing at a time :) > > -- > Cheers, > > David / dhildenb >
