Message-ID: <20170706164304.GA23662@castle>
Date:   Thu, 6 Jul 2017 17:43:04 +0100
From:   Roman Gushchin <guro@...com>
To:     Mel Gorman <mgorman@...hsingularity.net>
CC:     <linux-mm@...ck.org>, Andrew Morton <akpm@...ux-foundation.org>,
        Johannes Weiner <hannes@...xchg.org>,
        Michal Hocko <mhocko@...e.com>,
        Vladimir Davydov <vdavydov.dev@...il.com>,
        Rik van Riel <riel@...hat.com>, <kernel-team@...com>,
        <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] mm: make allocation counters per-order

On Thu, Jul 06, 2017 at 04:47:05PM +0100, Mel Gorman wrote:
> On Thu, Jul 06, 2017 at 03:46:34PM +0100, Roman Gushchin wrote:
> > > The alloc counter updates are themselves a surprisingly heavy cost to
> > > the allocation path and this makes it worse for a debugging case that is
> > > relatively rare. I'm extremely reluctant for such a patch to be added
> > > given that the tracepoints can be used to assemble such a monitor even
> > > if it means running a userspace daemon to keep track of it. Would such a
> > > solution be suitable? Failing that if this is a severe issue, would it be
> > > possible to at least make this a compile-time or static tracepoint option?
> > > That way, only people that really need it have to take the penalty.
> > 
> > I've tried to measure the difference with my patch applied and without
> > any accounting at all (__count_alloc_event() redefined to an empty function),
> > and I wasn't able to find any measurable difference.
> > Can you, please, provide more details, how your scenario looked like,
> > when alloc coutners were costly?
> > 
> 
> At the time I used a page allocator microbenchmark from mmtests to call
> the allocator directly without zeroing pages. Triggering allocations from
> userspace generally mask the overhead by the zeroing costs. It's just a few
> cycles but given the budget for the page allocator in some circumstances
> is tiny, it was noticable. perf was used to examine the cost.

I'll try to measure the difference with mmtests.

I agree, that it's not a feature that worth significant performance penalty,
but if it's small even in a special benchmark, I'd say, it's acceptable.

> > As new counters replace an old one, and both are per-cpu counters, I believe,
> > that the difference should be really small.
> > 
> 
> Minimally you add a new branch and a small number of computations. It's
> small but it's there. The cache footprint of the counters is also increased.
> That is hard to take given that it's overhead for everybody on the off-chance
> it can debug something.
> 
> It's not a strong objection and I won't nak it on this basis but given
> that the same information can be easily obtained using tracepoints
> (optionally lower overhead with systemtap), the information is rarely
> going to be useful (no latency information for example) and there is an
> increased maintenance cost then it does not seem to be that useful.

Tracepoints are good for investigations on one machine, not so convenient
if we are talking about gathering stats from the fleet with production load.
Unfortunately, some memory fragmentation issues are hard to reproduce on
a single dev machine.

> Maybe it would be slightly more convincing if there was an example of
> real problems in the field that can be debugged with this. For high-order
> allocations, I previously found that it was the latency that was of the
> most concern and not the absolute count that happened since the system
> started.

We met an issue with compaction consuming too much CPU under some specific
conditions, and one of the suspicions was a significant number of high-order
allocations, requested by some third-party device drivers.

Knowing the number of allocations is especially helpful for comparing
different kernel versions in a such case, as it's hard to distinguish changes
in mm, changes in these drivers or just workload/environment changes,
leaded to an increased or decreased fragmentation.

Roman

Powered by blists - more mailing lists