All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@kernel.org>
To: Janani Ravichandran <janani.rvchndrn@gmail.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	riel@surriel.com, akpm@linux-foundation.org,
	vdavydov@virtuozzo.com, vbabka@suse.cz,
	mgorman@techsingularity.net, rostedt@goodmis.org
Subject: Re: [RFC] scripts: Include postprocessing script for memory allocation tracing
Date: Thu, 6 Oct 2016 14:00:50 +0200	[thread overview]
Message-ID: <20161006120050.GG10570@dhcp22.suse.cz> (raw)
In-Reply-To: <20160923080709.GB4478@dhcp22.suse.cz>

On Fri 23-09-16 10:07:09, Michal Hocko wrote:
> On Thu 22-09-16 11:30:36, Janani Ravichandran wrote:
> > 
> > > On Sep 19, 2016, at 5:42 AM, Michal Hocko <mhocko@kernel.org> wrote:
> > > 
> > > On Tue 13-09-16 14:04:49, Janani Ravichandran wrote:
> > >> 
> > >>> On Sep 12, 2016, at 8:16 AM, Michal Hocko <mhocko@kernel.org> wrote:
> > >> 
> > >> I’m using the function graph tracer to see how long __alloc_pages_nodemask()
> > >> took.
> > > 
> > > How can you map the function graph tracer to a specif context? Let's say
> > > I would like to know why a particular allocation took so long. Would
> > > that be possible?
> > 
> > Maybe not. If the latencies are due to direct reclaim or memory compaction, you
> > get some information from the tracepoints (like mm_vmscan_direct_reclaim_begin,
> > mm_compaction_begin, etc). But otherwise, you don’t get any context information. 
> > Function graph only gives the time spent in alloc_pages_nodemask() in that case.
> 
> Then I really think that we need a starting trace point. I think that
> having the full context information is really helpful in order to
> understand latencies induced by allocations.

Are you planning to pursue this path?
-- 
Michal Hocko
SUSE Labs

WARNING: multiple messages have this Message-ID (diff)
From: Michal Hocko <mhocko@kernel.org>
To: Janani Ravichandran <janani.rvchndrn@gmail.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	riel@surriel.com, akpm@linux-foundation.org,
	vdavydov@virtuozzo.com, vbabka@suse.cz,
	mgorman@techsingularity.net, rostedt@goodmis.org
Subject: Re: [RFC] scripts: Include postprocessing script for memory allocation tracing
Date: Thu, 6 Oct 2016 14:00:50 +0200	[thread overview]
Message-ID: <20161006120050.GG10570@dhcp22.suse.cz> (raw)
In-Reply-To: <20160923080709.GB4478@dhcp22.suse.cz>

On Fri 23-09-16 10:07:09, Michal Hocko wrote:
> On Thu 22-09-16 11:30:36, Janani Ravichandran wrote:
> > 
> > > On Sep 19, 2016, at 5:42 AM, Michal Hocko <mhocko@kernel.org> wrote:
> > > 
> > > On Tue 13-09-16 14:04:49, Janani Ravichandran wrote:
> > >> 
> > >>> On Sep 12, 2016, at 8:16 AM, Michal Hocko <mhocko@kernel.org> wrote:
> > >> 
> > >> Ia??m using the function graph tracer to see how long __alloc_pages_nodemask()
> > >> took.
> > > 
> > > How can you map the function graph tracer to a specif context? Let's say
> > > I would like to know why a particular allocation took so long. Would
> > > that be possible?
> > 
> > Maybe not. If the latencies are due to direct reclaim or memory compaction, you
> > get some information from the tracepoints (like mm_vmscan_direct_reclaim_begin,
> > mm_compaction_begin, etc). But otherwise, you dona??t get any context information. 
> > Function graph only gives the time spent in alloc_pages_nodemask() in that case.
> 
> Then I really think that we need a starting trace point. I think that
> having the full context information is really helpful in order to
> understand latencies induced by allocations.

Are you planning to pursue this path?
-- 
Michal Hocko
SUSE Labs

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

  reply	other threads:[~2016-10-06 12:01 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-11 22:24 [RFC] scripts: Include postprocessing script for memory allocation tracing Janani Ravichandran
2016-09-11 22:24 ` Janani Ravichandran
2016-09-12 12:16 ` Michal Hocko
2016-09-12 12:16   ` Michal Hocko
2016-09-13 18:04   ` Janani Ravichandran
2016-09-13 18:04     ` Janani Ravichandran
2016-09-19  9:42     ` Michal Hocko
2016-09-19  9:42       ` Michal Hocko
2016-09-22 15:30       ` Janani Ravichandran
2016-09-22 15:30         ` Janani Ravichandran
2016-09-23  8:07         ` Michal Hocko
2016-09-23  8:07           ` Michal Hocko
2016-10-06 12:00           ` Michal Hocko [this message]
2016-10-06 12:00             ` Michal Hocko
2016-10-11 14:43           ` Janani Ravichandran
2016-10-11 14:43             ` Janani Ravichandran
2016-10-15 23:31             ` Janani Ravichandran
2016-10-15 23:31               ` Janani Ravichandran
2016-10-16  7:33               ` Michal Hocko
2016-10-16  7:33                 ` Michal Hocko
     [not found]                 ` <CANnt6X=RpSnuxGXZfF6Qa5mJpzC8gL3wkKJi3tQMZJBZJVWF3w@mail.gmail.com>
2016-10-17 17:31                   ` Janani Ravichandran
2016-10-18 13:13                     ` Michal Hocko
2016-10-18 13:13                       ` Michal Hocko
2016-10-20 23:10                       ` Janani Ravichandran
2016-10-20 23:10                         ` Janani Ravichandran
2016-10-21  7:08                         ` Michal Hocko
2016-10-21  7:08                           ` Michal Hocko
2016-10-27 15:42                           ` Janani Ravichandran
2016-10-27 15:42                             ` Janani Ravichandran
  -- strict thread matches above, loose matches on Subject: below --
2016-08-19 11:38 Janani Ravichandran
2016-08-19 11:38 ` Janani Ravichandran

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=20161006120050.GG10570@dhcp22.suse.cz \
    --to=mhocko@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=janani.rvchndrn@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@techsingularity.net \
    --cc=riel@surriel.com \
    --cc=rostedt@goodmis.org \
    --cc=vbabka@suse.cz \
    --cc=vdavydov@virtuozzo.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.