Re: [PATCH] Hugepages should be accounted as unevictable pages.

KOSAKI Motohiro
2009-06-23T05:05:57Z

> > > Unevictable: 0 kB
> > > Mlocked: 0 kB
> > > HugePages_Total: 20
> > > HugePages_Free: 20
> > > HugePages_Rsvd: 0
> > > HugePages_Surp: 0
> > >
> > > After the patch:
> > >
> > > Unevictable: 81920 kB
> > > Mlocked: 0 kB
> > > HugePages_Total: 20
> > > HugePages_Free: 20
> > > HugePages_Rsvd: 0
> > > HugePages_Surp: 0
> >
> > At first, We should clarify the spec of unevictable.
> > Currently, Unevictable field mean the number of pages in unevictable-lru
> > and hugepage never insert any lru.
> >
> > I think this patch will change this rule.
>
> I agree, and that's why I added a comment to the documentation file to
> that effect. If you think its not explicit or doesn't explain what its
> supposed to we can add something more there.
>
> IMO, the proc output should give the total number of unevictable pages
> in the system and, since hugepages are also in fact unevictable so I
> don't see a reason why they shouldn't be accounted accordingly.
> What do you think ?

ummm...

I'm not sure this unevictable definition is good idea or not. currently
hugepage isn't only non-account memory, but also various kernel memory doesn't
account.

one of drawback is that zone_page_state(UNEVICTABLE) lost to mean #-of-unevictable-pages.
e.g. following patch is wrong?

fs/proc/meminfo.c meminfo_proc_show()
----------------------------
- K(pages[LRU_UNEVICTABLE]),
+ K(pages[LRU_UNEVICTABLE]) + hstate->nr_huge_pages,

Plus, I didn't find any practical benefit in this patch. do you have it?
or You only want to natural definition?

I don't have any strong oppose reason, but I also don't have any strong
agree reason.

Lee, What do you think?