On (02/19/16 10:39), Joonsoo Kim wrote:
[..]
> > not sure if it's worth mentioning in the comment, but the other
> > concern here is the performance impact of an extra function call,
> > I believe. otherwise, Joonsoo would just do:
>
> It's very natural thing so I'm not sure it is worth
On (02/19/16 10:39), Joonsoo Kim wrote:
[..]
> > not sure if it's worth mentioning in the comment, but the other
> > concern here is the performance impact of an extra function call,
> > I believe. otherwise, Joonsoo would just do:
>
> It's very natural thing so I'm not sure it is worth
On Fri, 19 Feb 2016 10:39:10 +0900
Joonsoo Kim wrote:
> > not sure if it's worth mentioning in the comment, but the other
> > concern here is the performance impact of an extra function call,
> > I believe. otherwise, Joonsoo would just do:
>
> It's very natural thing so
On Fri, 19 Feb 2016 10:39:10 +0900
Joonsoo Kim wrote:
> > not sure if it's worth mentioning in the comment, but the other
> > concern here is the performance impact of an extra function call,
> > I believe. otherwise, Joonsoo would just do:
>
> It's very natural thing so I'm not sure it is
2016-02-19 9:34 GMT+09:00 Sergey Senozhatsky
:
> On (02/18/16 09:29), Steven Rostedt wrote:
>> > diff --git a/include/linux/page_ref.h b/include/linux/page_ref.h
>> > index 534249c..fd6d9a5 100644
>> > --- a/include/linux/page_ref.h
>> > +++
2016-02-19 9:34 GMT+09:00 Sergey Senozhatsky
:
> On (02/18/16 09:29), Steven Rostedt wrote:
>> > diff --git a/include/linux/page_ref.h b/include/linux/page_ref.h
>> > index 534249c..fd6d9a5 100644
>> > --- a/include/linux/page_ref.h
>> > +++ b/include/linux/page_ref.h
>> > @@ -1,6 +1,54 @@
>> >
2016-02-18 23:29 GMT+09:00 Steven Rostedt :
> On Mon, 15 Feb 2016 12:04:50 +0900
> js1...@gmail.com wrote:
>
>
>> diff --git a/include/linux/page_ref.h b/include/linux/page_ref.h
>> index 534249c..fd6d9a5 100644
>> --- a/include/linux/page_ref.h
>> +++
2016-02-18 23:29 GMT+09:00 Steven Rostedt :
> On Mon, 15 Feb 2016 12:04:50 +0900
> js1...@gmail.com wrote:
>
>
>> diff --git a/include/linux/page_ref.h b/include/linux/page_ref.h
>> index 534249c..fd6d9a5 100644
>> --- a/include/linux/page_ref.h
>> +++ b/include/linux/page_ref.h
>> @@ -1,6 +1,54
On (02/18/16 09:29), Steven Rostedt wrote:
> > diff --git a/include/linux/page_ref.h b/include/linux/page_ref.h
> > index 534249c..fd6d9a5 100644
> > --- a/include/linux/page_ref.h
> > +++ b/include/linux/page_ref.h
> > @@ -1,6 +1,54 @@
> > #include
> > #include
> > #include
> > +#include
>
On (02/18/16 09:29), Steven Rostedt wrote:
> > diff --git a/include/linux/page_ref.h b/include/linux/page_ref.h
> > index 534249c..fd6d9a5 100644
> > --- a/include/linux/page_ref.h
> > +++ b/include/linux/page_ref.h
> > @@ -1,6 +1,54 @@
> > #include
> > #include
> > #include
> > +#include
>
On Mon, 15 Feb 2016 12:04:50 +0900
js1...@gmail.com wrote:
> diff --git a/include/linux/page_ref.h b/include/linux/page_ref.h
> index 534249c..fd6d9a5 100644
> --- a/include/linux/page_ref.h
> +++ b/include/linux/page_ref.h
> @@ -1,6 +1,54 @@
> #include
> #include
> #include
> +#include
>
On Mon, 15 Feb 2016 12:04:50 +0900
js1...@gmail.com wrote:
> diff --git a/include/linux/page_ref.h b/include/linux/page_ref.h
> index 534249c..fd6d9a5 100644
> --- a/include/linux/page_ref.h
> +++ b/include/linux/page_ref.h
> @@ -1,6 +1,54 @@
> #include
> #include
> #include
> +#include
>
On Thu, 18 Feb 2016 16:46:08 +0900
Joonsoo Kim wrote:
> 2016-02-16 10:16 GMT+09:00 Steven Rostedt :
> > On Tue, 16 Feb 2016 09:47:20 +0900
> > Joonsoo Kim wrote:
> >
> >> > They return true when CONFIG_TRACEPOINTS is configured in
On Thu, 18 Feb 2016 16:46:08 +0900
Joonsoo Kim wrote:
> 2016-02-16 10:16 GMT+09:00 Steven Rostedt :
> > On Tue, 16 Feb 2016 09:47:20 +0900
> > Joonsoo Kim wrote:
> >
> >> > They return true when CONFIG_TRACEPOINTS is configured in and the
> >> > tracepoint is enabled, and false otherwise.
>
2016-02-16 10:16 GMT+09:00 Steven Rostedt :
> On Tue, 16 Feb 2016 09:47:20 +0900
> Joonsoo Kim wrote:
>
>> > They return true when CONFIG_TRACEPOINTS is configured in and the
>> > tracepoint is enabled, and false otherwise.
>>
>> This implementation is
2016-02-16 10:16 GMT+09:00 Steven Rostedt :
> On Tue, 16 Feb 2016 09:47:20 +0900
> Joonsoo Kim wrote:
>
>> > They return true when CONFIG_TRACEPOINTS is configured in and the
>> > tracepoint is enabled, and false otherwise.
>>
>> This implementation is what you proposed before. Please refer below
On Tue, 16 Feb 2016 09:47:20 +0900
Joonsoo Kim wrote:
> > They return true when CONFIG_TRACEPOINTS is configured in and the
> > tracepoint is enabled, and false otherwise.
>
> This implementation is what you proposed before. Please refer below
> link and source.
>
>
On Tue, 16 Feb 2016 09:47:20 +0900
Joonsoo Kim wrote:
> > They return true when CONFIG_TRACEPOINTS is configured in and the
> > tracepoint is enabled, and false otherwise.
>
> This implementation is what you proposed before. Please refer below
> link and source.
>
>
On Mon, Feb 15, 2016 at 11:07:41AM -0500, Steven Rostedt wrote:
> On Mon, 15 Feb 2016 12:04:50 +0900
> js1...@gmail.com wrote:
>
> > From: Joonsoo Kim
> >
> > CMA allocation should be guaranteed to succeed by definition, but,
> > unfortunately, it would be failed
On Mon, Feb 15, 2016 at 11:07:41AM -0500, Steven Rostedt wrote:
> On Mon, 15 Feb 2016 12:04:50 +0900
> js1...@gmail.com wrote:
>
> > From: Joonsoo Kim
> >
> > CMA allocation should be guaranteed to succeed by definition, but,
> > unfortunately, it would be failed sometimes. It is hard to track
On Mon, 15 Feb 2016 12:04:50 +0900
js1...@gmail.com wrote:
> From: Joonsoo Kim
>
> CMA allocation should be guaranteed to succeed by definition, but,
> unfortunately, it would be failed sometimes. It is hard to track down
> the problem, because it is related to page
On Mon, 15 Feb 2016 12:04:50 +0900
js1...@gmail.com wrote:
> From: Joonsoo Kim
>
> CMA allocation should be guaranteed to succeed by definition, but,
> unfortunately, it would be failed sometimes. It is hard to track down
> the problem, because it is related to page reference manipulation and
>
2016-02-15 14:28 GMT+09:00 Sergey Senozhatsky
:
> On (02/15/16 14:08), Sergey Senozhatsky wrote:
>>
>> will this compile with !CONFIG_TRACEPOINTS config?
>>
Yes, even if !CONFIG_TRACEPOINTS, it is compiled well.
> uh.. sorry, was composed in email client. seems
2016-02-15 14:28 GMT+09:00 Sergey Senozhatsky
:
> On (02/15/16 14:08), Sergey Senozhatsky wrote:
>>
>> will this compile with !CONFIG_TRACEPOINTS config?
>>
Yes, even if !CONFIG_TRACEPOINTS, it is compiled well.
> uh.. sorry, was composed in email client. seems the correct way to do it is
>
>
On (02/15/16 14:08), Sergey Senozhatsky wrote:
>
> will this compile with !CONFIG_TRACEPOINTS config?
>
uh.. sorry, was composed in email client. seems the correct way to do it is
+#if defined CONFIG_DEBUG_PAGE_REF && defined CONFIG_TRACEPOINTS
#include
#define
On (02/15/16 14:08), Sergey Senozhatsky wrote:
>
> will this compile with !CONFIG_TRACEPOINTS config?
>
uh.. sorry, was composed in email client. seems the correct way to do it is
+#if defined CONFIG_DEBUG_PAGE_REF && defined CONFIG_TRACEPOINTS
#include
#define
Hello Joonsoo,
On (02/15/16 12:04), js1...@gmail.com wrote:
[..]
> <...>-9018 [004]92.678375: page_ref_set: pfn=0x17ac9 flags=0x0
> count=1 mapcount=0 mapping=(nil) mt=4 val=1
> <...>-9018 [004]92.678378: kernel_stack:
> => get_page_from_freelist (81176659)
> =>
Hello Joonsoo,
On (02/15/16 12:04), js1...@gmail.com wrote:
[..]
> <...>-9018 [004]92.678375: page_ref_set: pfn=0x17ac9 flags=0x0
> count=1 mapcount=0 mapping=(nil) mt=4 val=1
> <...>-9018 [004]92.678378: kernel_stack:
> => get_page_from_freelist (81176659)
> =>
From: Joonsoo Kim
CMA allocation should be guaranteed to succeed by definition, but,
unfortunately, it would be failed sometimes. It is hard to track down
the problem, because it is related to page reference manipulation and
we don't have any facility to analyze it.
This
From: Joonsoo Kim
CMA allocation should be guaranteed to succeed by definition, but,
unfortunately, it would be failed sometimes. It is hard to track down
the problem, because it is related to page reference manipulation and
we don't have any facility to analyze it.
This patch adds tracepoints
On Wed, Dec 09, 2015 at 10:36:48PM -0500, Steven Rostedt wrote:
> On Thu, 10 Dec 2015 11:50:15 +0900
> Joonsoo Kim wrote:
>
> > Output of cpu 3, 7 are mixed and it's not easy to analyze it.
> >
> > I think that it'd be better not to sort stack trace. How do
> > you think about it? Could you fix
On Thu, 10 Dec 2015 11:50:15 +0900
Joonsoo Kim wrote:
> Output of cpu 3, 7 are mixed and it's not easy to analyze it.
>
> I think that it'd be better not to sort stack trace. How do
> you think about it? Could you fix it, please?
It may not be that easy to fix because of the sorting algorithm.
On Wed, Dec 09, 2015 at 03:01:54PM -0500, Steven Rostedt wrote:
> On Thu, 3 Dec 2015 13:16:58 +0900
> Joonsoo Kim wrote:
>
> > On Tue, Nov 24, 2015 at 10:45:28AM +0900, Joonsoo Kim wrote:
> > > On Mon, Nov 23, 2015 at 09:26:04AM -0500, Steven Rostedt wrote:
> > > > On Mon, 23 Nov 2015 17:28:05
On Thu, 3 Dec 2015 13:16:58 +0900
Joonsoo Kim wrote:
> On Tue, Nov 24, 2015 at 10:45:28AM +0900, Joonsoo Kim wrote:
> > On Mon, Nov 23, 2015 at 09:26:04AM -0500, Steven Rostedt wrote:
> > > On Mon, 23 Nov 2015 17:28:05 +0900
> > > Joonsoo Kim wrote:
> > >
> > > > On Fri, Nov 20, 2015 at
On Thu, 10 Dec 2015 11:50:15 +0900
Joonsoo Kim wrote:
> Output of cpu 3, 7 are mixed and it's not easy to analyze it.
>
> I think that it'd be better not to sort stack trace. How do
> you think about it? Could you fix it, please?
It may not be that easy to fix because
On Wed, Dec 09, 2015 at 10:36:48PM -0500, Steven Rostedt wrote:
> On Thu, 10 Dec 2015 11:50:15 +0900
> Joonsoo Kim wrote:
>
> > Output of cpu 3, 7 are mixed and it's not easy to analyze it.
> >
> > I think that it'd be better not to sort stack trace. How do
> > you think
On Wed, Dec 09, 2015 at 03:01:54PM -0500, Steven Rostedt wrote:
> On Thu, 3 Dec 2015 13:16:58 +0900
> Joonsoo Kim wrote:
>
> > On Tue, Nov 24, 2015 at 10:45:28AM +0900, Joonsoo Kim wrote:
> > > On Mon, Nov 23, 2015 at 09:26:04AM -0500, Steven Rostedt wrote:
> > > > On
On Thu, 3 Dec 2015 13:16:58 +0900
Joonsoo Kim wrote:
> On Tue, Nov 24, 2015 at 10:45:28AM +0900, Joonsoo Kim wrote:
> > On Mon, Nov 23, 2015 at 09:26:04AM -0500, Steven Rostedt wrote:
> > > On Mon, 23 Nov 2015 17:28:05 +0900
> > > Joonsoo Kim
On Tue, Nov 24, 2015 at 10:45:28AM +0900, Joonsoo Kim wrote:
> On Mon, Nov 23, 2015 at 09:26:04AM -0500, Steven Rostedt wrote:
> > On Mon, 23 Nov 2015 17:28:05 +0900
> > Joonsoo Kim wrote:
> >
> > > On Fri, Nov 20, 2015 at 11:42:25AM -0500, Steven Rostedt wrote:
> > > > On Fri, 20 Nov 2015
On Tue, Nov 24, 2015 at 10:45:28AM +0900, Joonsoo Kim wrote:
> On Mon, Nov 23, 2015 at 09:26:04AM -0500, Steven Rostedt wrote:
> > On Mon, 23 Nov 2015 17:28:05 +0900
> > Joonsoo Kim wrote:
> >
> > > On Fri, Nov 20, 2015 at 11:42:25AM -0500, Steven Rostedt wrote:
> > > >
On Mon, Nov 23, 2015 at 09:26:04AM -0500, Steven Rostedt wrote:
> On Mon, 23 Nov 2015 17:28:05 +0900
> Joonsoo Kim wrote:
>
> > On Fri, Nov 20, 2015 at 11:42:25AM -0500, Steven Rostedt wrote:
> > > On Fri, 20 Nov 2015 15:33:25 +0900
> > > Joonsoo Kim wrote:
> > >
> > >
> > > > Steven, is it
On Mon, Nov 23, 2015 at 09:26:04AM -0500, Steven Rostedt wrote:
> On Mon, 23 Nov 2015 17:28:05 +0900
> Joonsoo Kim wrote:
>
> > On Fri, Nov 20, 2015 at 11:42:25AM -0500, Steven Rostedt wrote:
> > > On Fri, 20 Nov 2015 15:33:25 +0900
> > > Joonsoo Kim wrote:
> > >
> > >
> > > > Steven, is it
On Mon, 23 Nov 2015 17:28:05 +0900
Joonsoo Kim wrote:
> On Fri, Nov 20, 2015 at 11:42:25AM -0500, Steven Rostedt wrote:
> > On Fri, 20 Nov 2015 15:33:25 +0900
> > Joonsoo Kim wrote:
> >
> >
> > > Steven, is it possible to add tracepoint to inlined fucntion such as
> > > get_page() in
On Fri, Nov 20, 2015 at 11:42:25AM -0500, Steven Rostedt wrote:
> On Fri, 20 Nov 2015 15:33:25 +0900
> Joonsoo Kim wrote:
>
>
> > Steven, is it possible to add tracepoint to inlined fucntion such as
> > get_page() in include/linux/mm.h?
>
> I highly recommend against it. The tracepoint code
On Fri, Nov 20, 2015 at 11:42:25AM -0500, Steven Rostedt wrote:
> On Fri, 20 Nov 2015 15:33:25 +0900
> Joonsoo Kim wrote:
>
>
> > Steven, is it possible to add tracepoint to inlined fucntion such as
> > get_page() in include/linux/mm.h?
>
> I highly recommend against
On Mon, 23 Nov 2015 17:28:05 +0900
Joonsoo Kim wrote:
> On Fri, Nov 20, 2015 at 11:42:25AM -0500, Steven Rostedt wrote:
> > On Fri, 20 Nov 2015 15:33:25 +0900
> > Joonsoo Kim wrote:
> >
> >
> > > Steven, is it possible to add tracepoint to
On Mon, Nov 23, 2015 at 09:26:04AM -0500, Steven Rostedt wrote:
> On Mon, 23 Nov 2015 17:28:05 +0900
> Joonsoo Kim wrote:
>
> > On Fri, Nov 20, 2015 at 11:42:25AM -0500, Steven Rostedt wrote:
> > > On Fri, 20 Nov 2015 15:33:25 +0900
> > > Joonsoo Kim
On Mon, Nov 23, 2015 at 09:26:04AM -0500, Steven Rostedt wrote:
> On Mon, 23 Nov 2015 17:28:05 +0900
> Joonsoo Kim wrote:
>
> > On Fri, Nov 20, 2015 at 11:42:25AM -0500, Steven Rostedt wrote:
> > > On Fri, 20 Nov 2015 15:33:25 +0900
> > > Joonsoo Kim
On Fri, 20 Nov 2015 15:33:25 +0900
Joonsoo Kim wrote:
> Steven, is it possible to add tracepoint to inlined fucntion such as
> get_page() in include/linux/mm.h?
I highly recommend against it. The tracepoint code adds a bit of bloat,
and if you inline it, you add that bloat to every use case.
On Fri, 20 Nov 2015 15:33:25 +0900
Joonsoo Kim wrote:
> Steven, is it possible to add tracepoint to inlined fucntion such as
> get_page() in include/linux/mm.h?
I highly recommend against it. The tracepoint code adds a bit of bloat,
and if you inline it, you add that
Ccing Steven.
Hello,
On Wed, Nov 18, 2015 at 04:34:30PM +0100, Vlastimil Babka wrote:
> On 11/09/2015 08:23 AM, Joonsoo Kim wrote:
> > CMA allocation should be guaranteed to succeed by definition, but,
> > unfortunately, it would be failed sometimes. It is hard to track down
> > the problem,
Ccing Steven.
Hello,
On Wed, Nov 18, 2015 at 04:34:30PM +0100, Vlastimil Babka wrote:
> On 11/09/2015 08:23 AM, Joonsoo Kim wrote:
> > CMA allocation should be guaranteed to succeed by definition, but,
> > unfortunately, it would be failed sometimes. It is hard to track down
> > the problem,
On Wed, Nov 18, 2015 at 04:34:30PM +0100, Vlastimil Babka wrote:
> On 11/09/2015 08:23 AM, Joonsoo Kim wrote:
> > CMA allocation should be guaranteed to succeed by definition, but,
> > unfortunately, it would be failed sometimes. It is hard to track down
> > the problem, because it is related to
On 11/09/2015 08:23 AM, Joonsoo Kim wrote:
> CMA allocation should be guaranteed to succeed by definition, but,
> unfortunately, it would be failed sometimes. It is hard to track down
> the problem, because it is related to page reference manipulation and
> we don't have any facility to analyze
On 11/09/2015 08:23 AM, Joonsoo Kim wrote:
> CMA allocation should be guaranteed to succeed by definition, but,
> unfortunately, it would be failed sometimes. It is hard to track down
> the problem, because it is related to page reference manipulation and
> we don't have any facility to analyze
On Wed, Nov 18, 2015 at 04:34:30PM +0100, Vlastimil Babka wrote:
> On 11/09/2015 08:23 AM, Joonsoo Kim wrote:
> > CMA allocation should be guaranteed to succeed by definition, but,
> > unfortunately, it would be failed sometimes. It is hard to track down
> > the problem, because it is related to
On Mon, Nov 09 2015, Joonsoo Kim wrote:
> CMA allocation should be guaranteed to succeed by definition,
Uh? That’s a peculiar statement. Which is to say that it’s not true.
> but,
> unfortunately, it would be failed sometimes. It is hard to track down
> the problem, because it is related to
On Mon, Nov 09 2015, Joonsoo Kim wrote:
> CMA allocation should be guaranteed to succeed by definition,
Uh? That’s a peculiar statement. Which is to say that it’s not true.
> but,
> unfortunately, it would be failed sometimes. It is hard to track down
> the problem, because it is related to
CMA allocation should be guaranteed to succeed by definition, but,
unfortunately, it would be failed sometimes. It is hard to track down
the problem, because it is related to page reference manipulation and
we don't have any facility to analyze it.
This patch adds tracepoints to track down page
CMA allocation should be guaranteed to succeed by definition, but,
unfortunately, it would be failed sometimes. It is hard to track down
the problem, because it is related to page reference manipulation and
we don't have any facility to analyze it.
This patch adds tracepoints to track down page
60 matches
Mail list logo