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)
> =>
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
56 matches
Mail list logo