archive mirror
 help / color / mirror / Atom feed
From: Debabrata Banerjee <>
To: Mel Gorman <>
Cc: Roman Gushchin <>,, Andrew Morton <>,
	Johannes Weiner <>,
	Michal Hocko <>,
	Vladimir Davydov <>,
	Rik van Riel <>,,
	"" <>
Subject: Re: [PATCH] mm: make allocation counters per-order
Date: Thu, 6 Jul 2017 10:54:24 -0400	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Thu, Jul 6, 2017 at 9:19 AM, Mel Gorman <> 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.
> --
> Mel Gorman

We (Akamai) have been struggling with memory fragmentation issues for
years, and especially the inability to track positive or negative
changes to fragmentation between allocator changes and kernels without
simply looking for how many allocations are failing. We've had someone
toying with trying to report the same data via scanning all pages at
report time versus keeping running stats, although we don't have
working code yet. If it did work it would avoid the runtime overhead.
I don't believe tracepoints are a workable solution for us, since we
would have to be collecting the data from boot, as well as continually
processing the data in userspace at high cost. Ultimately the
locations and other properties (merge-ability) of the allocations in
the buddy groups are also important, which would be interesting to add
on-top of Roman's patch.

To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to  For more info on Linux MM,
see: .
Don't email: <a href=mailto:""> </a>

  parent reply	other threads:[~2017-07-06 14:54 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-06 13:04 [PATCH] mm: make allocation counters per-order Roman Gushchin
2017-07-06 13:19 ` Mel Gorman
2017-07-06 14:46   ` Roman Gushchin
2017-07-06 15:47     ` Mel Gorman
2017-07-06 16:43       ` Roman Gushchin
2017-07-06 17:16         ` Mel Gorman
2017-07-06 18:00           ` Debabrata Banerjee
2017-07-06 20:02             ` Mel Gorman
2017-07-16 13:27       ` Roman Gushchin
2017-07-16 13:29       ` Roman Gushchin
2017-07-16 13:55         ` [v2] " kbuild test robot
2017-07-06 14:54   ` Debabrata Banerjee [this message]
2017-07-06 15:51     ` [PATCH] " Mel Gorman
2017-07-06 16:12       ` Debabrata Banerjee
2017-07-06 16:43         ` Mel Gorman
2017-07-06 15:02 ` Christoph Lameter
2017-07-07  1:54 ` kbuild test robot
2017-07-07  6:06 ` kbuild test robot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='' \ \ \ \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).