linux-kernel - Re: [PATCH v1 0/2] mm: migrate: vm event counter for hugepage migration

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 12 Apr 2018 07:40:41 +0000
From:   Naoya Horiguchi <n-horiguchi@...jp.nec.com>
To:     Michal Hocko <mhocko@...nel.org>
CC:     "linux-mm@...ck.org" <linux-mm@...ck.org>,
        Zi Yan <zi.yan@...t.com>,
        "Kirill A. Shutemov" <kirill@...temov.name>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Vlastimil Babka <vbabka@...e.cz>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v1 0/2] mm: migrate: vm event counter for hugepage
 migration

On Thu, Apr 12, 2018 at 08:18:59AM +0200, Michal Hocko wrote:
> On Wed 11-04-18 17:09:25, Naoya Horiguchi wrote:
> > Hi everyone,
> > 
> > I wrote patches introducing separate vm event counters for hugepage migration
> > (both for hugetlb and thp.)
> > Hugepage migration is different from normal page migration in event frequency
> > and/or how likely it succeeds, so maintaining statistics for them in mixed
> > counters might not be helpful both for develors and users.
> 
> This is quite a lot of code to be added se we should better document
> what it is intended for. Sure I understand your reasonaning about huge
> pages are more likely to fail but is this really worth a separate
> counter? Do you have an example of how this would be useful?

Our customers periodically collect some log info to understand what
happened after system failures happen.  Then if we have separate counters
for hugepage migration and the values show some anomaly, that might
help admins and developers understand the issue more quickly.
We have other ways to get this info like checking /proc/pid/pagemap and
/proc/kpageflags, but they are costly and most users decide not to
collect them in periodical logging.

> 
> If we are there then what about different huge page sizes (for hugetlb)?
> Do we need per-hstate stats?

Yes, per-hstate counters are better. And existing hugetlb counters
htlb_buddy_alloc_* are also affected by this point.

> 
> In other words, is this really worth it?

Actually, I'm not sure at this point.

Thanks,
Naoya Horiguchi

> 
> >  include/linux/vm_event_item.h |   7 +++
> >  mm/migrate.c                  | 103 +++++++++++++++++++++++++++++++++++-------
> >  mm/vmstat.c                   |   8 ++++
> >  3 files changed, 102 insertions(+), 16 deletions(-)
> 
> -- 
> Michal Hocko
> SUSE Labs
>