[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <554AFEE6.3060803@huawei.com>
Date: Thu, 7 May 2015 13:57:58 +0800
From: Xie XiuQi <xiexiuqi@...wei.com>
To: Naoya Horiguchi <n-horiguchi@...jp.nec.com>,
"rostedt@...dmis.org" <rostedt@...dmis.org>,
"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>
CC: "mingo@...hat.com" <mingo@...hat.com>,
"kirill.shutemov@...ux.intel.com" <kirill.shutemov@...ux.intel.com>,
"koct9i@...il.com" <koct9i@...il.com>,
"hpa@...ux.intel.com" <hpa@...ux.intel.com>,
"hannes@...xchg.org" <hannes@...xchg.org>,
"iamjoonsoo.kim@....com" <iamjoonsoo.kim@....com>,
"luto@...capital.net" <luto@...capital.net>,
"nasa4836@...il.com" <nasa4836@...il.com>,
"gong.chen@...ux.intel.com" <gong.chen@...ux.intel.com>,
"bhelgaas@...gle.com" <bhelgaas@...gle.com>,
"bp@...e.de" <bp@...e.de>,
"tony.luck@...el.com" <tony.luck@...el.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-mm@...ck.org" <linux-mm@...ck.org>,
"jingle.chen@...wei.com" <jingle.chen@...wei.com>
Subject: Re: [PATCH v4 0/3] tracing: add trace event for memory-failure
On 2015/5/7 9:12, Naoya Horiguchi wrote:
> On Wed, Apr 29, 2015 at 07:14:27PM +0800, Xie XiuQi wrote:
>> Hi Naoya,
>>
>> Could you help to review and applied this series if possible.
>
> Sorry for late response, I was offline for several days due to national
> holidays.
It doesn't matter, wish you have a good holiday ;-)
>
> This patchset is good to me, but I'm not sure which path it should go through.
> Ordinarily, memory-failure patches go to linux-mm, but patch 3 depends on
> TRACE_DEFINE_ENUM patches, so this can go to linux-next directly, or go to
> linux-mm with depending patches.
TRACE_DEFINE_ENUM patches has been merged into mainline. I'll correct patch 3's typo
and rebase them on top of latest mainline in v5.
Thanks,
Xie XiuQi
>
> Steven, Andrew, which way do you like?
>
> Thanks,
> Naoya Horiguchi
>
>> Thanks,
>> Xie XiuQi
>>
>> On 2015/4/20 16:44, Xie XiuQi wrote:
>>> RAS user space tools like rasdaemon which base on trace event, could
>>> receive mce error event, but no memory recovery result event. So, I
>>> want to add this event to make this scenario complete.
>>>
>>> This patchset add a event at ras group for memory-failure.
>>>
>>> The output like below:
>>> # tracer: nop
>>> #
>>> # entries-in-buffer/entries-written: 2/2 #P:24
>>> #
>>> # _-----=> irqs-off
>>> # / _----=> need-resched
>>> # | / _---=> hardirq/softirq
>>> # || / _--=> preempt-depth
>>> # ||| / delay
>>> # TASK-PID CPU# |||| TIMESTAMP FUNCTION
>>> # | | | |||| | |
>>> mce-inject-13150 [001] .... 277.019359: memory_failure_event: pfn 0x19869: recovery action for free buddy page: Delayed
>>>
>>> --
>>> v3->v4:
>>> - rebase on top of latest linux-next
>>> - update comments as Naoya's suggestion
>>> - add #ifdef CONFIG_MEMORY_FAILURE for this trace event
>>> - change type of action_result's param 3 to enum
>>>
>>> v2->v3:
>>> - rebase on top of linux-next
>>> - based on Steven Rostedt's "tracing: Add TRACE_DEFINE_ENUM() macro
>>> to map enums to their values" patch set v1.
>>>
>>> v1->v2:
>>> - Comment update
>>> - Just passing 'result' instead of 'action_name[result]',
>>> suggested by Steve. And hard coded there because trace-cmd
>>> and perf do not have a way to process enums.
>>>
>>> Xie XiuQi (3):
>>> memory-failure: export page_type and action result
>>> memory-failure: change type of action_result's param 3 to enum
>>> tracing: add trace event for memory-failure
>>>
>>> include/linux/mm.h | 34 ++++++++++
>>> include/ras/ras_event.h | 85 ++++++++++++++++++++++++
>>> mm/memory-failure.c | 172 ++++++++++++++++++++----------------------------
>>> 3 files changed, 190 insertions(+), 101 deletions(-)
>>>
>>
>> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
> .
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists