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:	Mon, 26 Nov 2012 09:35:28 +0000
From:	Mel Gorman <mgorman@...e.de>
To:	Hillf Danton <dhillf@...il.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/3] balancenuma: add stats for huge pmd numa faults

On Sun, Nov 25, 2012 at 02:14:12PM +0800, Hillf Danton wrote:
> On 11/24/12, Mel Gorman <mgorman@...e.de> wrote:
> > On Sat, Nov 24, 2012 at 12:17:03PM +0800, Hillf Danton wrote:
> >> A thp contributes 512 times more than a regular page to numa fault stats,
> >> so deserves its own vm event counter. THP migration is also accounted.
> >>
> >
> > I agree and mentioned it needed fixing. I did not create a new counter
> > but I properly account for PGMIGRATE_SUCCESS and PGMIGRATE_FAIL now. I
> > did not create a new NUMA_PAGE_MIGRATE counter because I didn't feel it
> > was necessary. Instead I just do this
> >
> >         count_vm_events(PGMIGRATE_SUCCESS, HPAGE_PMD_NR);
> >
>
> It could be read as: 512 pages are successfully migrated(though at the
> cost of actually one page).
> 

512 pages had to be copied and copy is a big part of the cost.

> >         count_vm_numa_events(NUMA_PAGE_MIGRATE, HPAGE_PMD_NR);
> >
>
> ditto, 512 pages go through migration(though actually only one page
> takes the hard journey).
> 

In my mind, the primary use of the counter is to estimate how many MB/sec
are being copied. If measured just once, the copy rate is averaged over the
duration of the test. If it's being regularly measured it can be determined
if the copying happens in bursts or is steady copying throughout.  For this,
just one counter is necessary as long as it counts the number of base
pages properly.

> That said, in short, the new counters are different and clearer.
> 

What new information does an extra counter give us that we can draw useful
conclusions from? It does not tell us much that is new about the data being
copied. It also do not tell us very much that is useful about THP because
the number of THP splits or collapses is more interesting (higher splits
or fewer collapses implies with THP which may be a net loss).

-- 
Mel Gorman
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ