> On Mar 8, 2022, at 6:14 AM, David Hildenbrand <david@xxxxxxxxxx> wrote: > > We want to pass the flags to more than one anon rmap function, getting > rid of special "do_page_add_anon_rmap()". So let's pass around a distinct > __bitwise type and refine documentation. > > Signed-off-by: David Hildenbrand <david@xxxxxxxxxx> > --- > include/linux/rmap.h | 22 ++++++++++++++++++---- > mm/memory.c | 6 +++--- > mm/rmap.c | 7 ++++--- > 3 files changed, 25 insertions(+), 10 deletions(-) > > diff --git a/include/linux/rmap.h b/include/linux/rmap.h > index 92c3585b8c6a..49f6b208938c 100644 > --- a/include/linux/rmap.h > +++ b/include/linux/rmap.h > @@ -158,9 +158,23 @@ static inline void anon_vma_merge(struct vm_area_struct *vma, > > struct anon_vma *page_get_anon_vma(struct page *page); > > -/* bitflags for do_page_add_anon_rmap() */ > -#define RMAP_EXCLUSIVE 0x01 > -#define RMAP_COMPOUND 0x02 > +/* RMAP flags, currently only relevant for some anon rmap operations. */ > +typedef int __bitwise rmap_t; > + > +/* > + * No special request: if the page is a subpage of a compound page, it is > + * mapped via a PTE. The mapped (sub)page is possibly shared between processes. > + */ > +#define RMAP_NONE ((__force rmap_t)0) > + > +/* The (sub)page is exclusive to a single process. */ > +#define RMAP_EXCLUSIVE ((__force rmap_t)BIT(0)) > + > +/* > + * The compound page is not mapped via PTEs, but instead via a single PMD and > + * should be accounted accordingly. > + */ > +#define RMAP_COMPOUND ((__force rmap_t)BIT(1)) I was once shouted at for a similar suggestion, but I am going to try once more… If you already define a new type, why not to use bitfields? It would be much easier to read. The last time I made such a suggestion, Ingo said "I personally like bitfields in theory … [but] older versions of GCC did a really poor job of optimizing them.” At the time (2014), I looked at GCC-4.4 and GCC-4.8 and there were some differences in the quality of the generated code. Is it still the case?
