Re: [PATCH v7 2/2] Refactor part of the oom report in dump_header

Hi Mike > My question was why do you call to alloc_constrained in the dump_header() > function rather than pass the constraint that was detected a bit earlier to > that function? dump_header will be called by three functions: oom_kill_process, check_panic_on_oom, out_of_memory. We can get the

Re: [PATCH v7 2/2] Refactor part of the oom report in dump_header

Hi Mike > Please keep the brief description of the function actually brief and move the > detailed explanation after the parameters description. Thanks for your advice. > The allocation constraint is detected by the dump_header() callers, why not > just use it here? David suggest that

Re: [PATCH v7 2/2] Refactor part of the oom report in dump_header

f it is 0. origin_memcg_name will be "(null)". I've tested !memcg OOM case with CONFIG_MEMCG and !CONFIG_MEMCG, and found nothing wrong. Thanks Wind 禹舟键 于2018年6月4日周一 上午9:58写道： > > Hi Mike > > Please keep the brief description of the function actually brief and move > > the deta

Re: [PATCH v7 2/2] Refactor part of the oom report in dump_header

Hi Mike > My question was why do you call to alloc_constrained in the dump_header() >function rather than pass the constraint that was detected a bit earlier to >that function? Ok, I will add a new parameter in the dump_header. Thank you.

Re: [PATCH v7 2/2] Refactor part of the oom report in dump_header

Hi Michal I will add the missing information in the cover-letter. > That being said, I am ready to ack a patch which adds the memcg of the > oom victim. I will not ack (nor nack) the patch which turns it into a > single print because I am not sure the benefit is really worth it. Maybe > others

Re: [PATCH v7 2/2] Refactor part of the oom report in dump_header

Hi Tetsuo I know what you mean. Actully I refer to the code for kernel version: 3.10.0-514. I think I can just use an array of type char, rather than static char. Is it right? Thanks

Re: [PATCH v7 2/2] Refactor part of the oom report in dump_header

Hi Michal > I have earlier suggested that you split this into two parts. One to add > the missing information and the later to convert it to a single printk > output. I'm sorry I do not get your point. What do you mean the missing information? > but it still really begs an example why we

[PATCH v7 1/2] Add an array of const char and enum oom_constraint in memcontrol.h

From: yuzhoujian This patch will make some preparation for the follow-up patch: Refactor part of the oom report in dump_header. It puts enum oom_constraint in memcontrol.h and adds an array of const char for each constraint. Signed-off-by: yuzhoujian --- include/linux/memcontrol.h | 14

Re: [PATCH v11 1/2] Refactor part of the oom report in dump_header

Hi Michal cpuset_print_current_mems_allowed is also invoked by warn_alloc(page_alloc.c). So, can I remove the current->comm output in the pr_info ? diff --git a/kernel/cgroup/cpuset.c b/kernel/cgroup/cpuset.c index d8b12e0d39cd..09b8ef6186c6 100644 --- a/kernel/cgroup/cpuset.c +++

Re: [PATCH v11 1/2] Refactor part of the oom report in dump_header

Hi Andy The const char array need to be used by the new func mem_cgroup_print_oom_context and some funcs in oom_kill.c in the second patch. Thanks > > On Sat, Jun 30, 2018 at 7:38 PM, wrote: > > From: yuzhoujian > > > > The current system wide oom report prints information about the victim >

Re: [PATCH v9] Refactor part of the oom report in dump_header

Hi Michal > diff --git a/include/linux/oom.h b/include/linux/oom.h > index 6adac113e96d..5bed78d4bfb8 100644 > --- a/include/linux/oom.h > +++ b/include/linux/oom.h > @@ -15,6 +15,20 @@ struct notifier_block; > struct mem_cgroup; > struct task_struct; > > +enum oom_constraint { > +

Re: [PATCH v9] Refactor part of the oom report in dump_header

parts, am I right ? Michal Hocko 于2018年6月22日周五 下午6:42写道： > > On Fri 22-06-18 17:33:12, 禹舟键 wrote: > > Hi Michal > > > diff --git a/include/linux/oom.h b/include/linux/oom.h > > > index 6adac113e96d..5bed78d4bfb8 100644 > > > --- a/include/linux/oom.h > >

Re: [LKP] [mm, oom] c1e4c54f9c: BUG:KASAN:null-ptr-deref_in_d

Hi Michal and David, AFAICS, the null pointer is the task_struct of p in the dump_header. Why don't we just add a if before printing the victim task's informaiton. diff --git a/mm/oom_kill.c b/mm/oom_kill.c --- a/mm/oom_kill.c +++ b/mm/oom_kill.c @@ -438,14 +438,6 @@ static void

Re: [LKP] [mm, oom] c1e4c54f9c: BUG:KASAN:null-ptr-deref_in_d

Hi Michal Sorry, I cannot open the link you shared.

Re: [PATCH v13 2/2] Add oom victim's memcg to the oom context information

Hi David Could I use use plain old %d? Just like this, pr_cont(",task=%s,pid=%d,uid=%d\n", p->comm, p->pid, from_kuid(_user_ns, task_uid(p))); Thanks

Re: [PATCH v14 1/2] Reorganize the oom report in dump_header

Hi Michal OK, thanks. Is there any problems for V14? Thanks

Re: [PATCH v11 1/2] Refactor part of the oom report in dump_header

Hi Michal and Andy The enum oom_constraint will be added in the struct oom_control. So I still think I should define it in oom.h. Michal Hocko 于2018年7月4日周三 下午4:17写道： > > On Wed 04-07-18 10:25:30, 禹舟键 wrote: > > Hi Andy > > The const char array need to be us

Re: [PATCH v13 2/2] Add oom victim's memcg to the oom context information

Hi Michal Sorry , I l forget to update the changlog for the second patch, but the cpuset information is not missing. Do I still need to make the v14 or just update the changelog for v13? Thanks

Re: [PATCH v13 2/2] Add oom victim's memcg to the oom context information

Hi Michal I think the single line output you want is just like that: oom-kill:constraint=,nodemask=,cpuset=,mems_allowed=,oom_memcg=,task_memcg=,task=,pid=,uid= Am I right?

Re: [PATCH] Add input file_name support for perf sched {map|latency|replay|timehist}

PING yuzhoujian 于2019年9月3日周二 下午4:56写道： > > From: YuZhoujian > > Just add '-i' option for perf sched {map|latency|replay|timehist} > > Signed-off-by: YuZhoujian > --- > tools/perf/Documentation/perf-sched.txt | 7 +++ > tools/perf/builtin-sched.c | 4 > 2 files changed,

Re: [PATCH] perf record: Add support to collect callchains from kernel or user space only.

Hi Arnaldo, Jirka > perf_event_attr.exclude_callchain_kernel to 0 I don't think we should set 0 for the desired callchins, because we will set exclude_callchain_user to 1 if perf_evsel is function event. void perf_evsel__config(struct perf_evsel *evsel, struct record_opts *opts, struct

Re: [PATCH] perf record: Add support to collect callchains from kernel or user space only.

PING ufo19890607 于2019年5月30日周四 下午9:29写道： > > From: yuzhoujian > > One can just record callchains in the kernel or user space with > this new options. We can use it together with "--all-kernel" options. > This two options is used just like print_stack(sys) or print_ustack(usr) > for systemtap.

Re: [PATCH] sched/debug: Show intergroup and hierarchy sum wait time of a task group

Hi Michael > Task competition inside a cgroup won't be considered as cgroup's > competition, please try create another cgroup with dead loop on > each CPU Yes, you are right, but I don't think we just need to account for cgroup's competition, because this factor does not reflect cgroup internal

Re: [PATCH] sched/debug: Show intergroup and hierarchy sum wait time of a task group

Hi Peter > The problem I have with this is that it will make schedstats even more expensive :/ I think the overhead for accounting hierarchy wait time is just the same as cpuacct.usage. If the performance overhead is low enough(< 1%), is it acceptable? Thanks Yuzhoujian Peter Zijlstra

Re: [PATCH v13 2/2] Add oom victim's memcg to the oom context information

Hi Michal Sorry , I l forget to update the changlog for the second patch, but the cpuset information is not missing. Do I still need to make the v14 or just update the changelog for v13? Thanks

Re: [PATCH v13 2/2] Add oom victim's memcg to the oom context information

Hi Michal I think the single line output you want is just like that: oom-kill:constraint=,nodemask=,cpuset=,mems_allowed=,oom_memcg=,task_memcg=,task=,pid=,uid= Am I right?

Re: [PATCH v9] Refactor part of the oom report in dump_header

Hi Michal > diff --git a/include/linux/oom.h b/include/linux/oom.h > index 6adac113e96d..5bed78d4bfb8 100644 > --- a/include/linux/oom.h > +++ b/include/linux/oom.h > @@ -15,6 +15,20 @@ struct notifier_block; > struct mem_cgroup; > struct task_struct; > > +enum oom_constraint { > +

Re: [PATCH v9] Refactor part of the oom report in dump_header

parts, am I right ? Michal Hocko 于2018年6月22日周五 下午6:42写道： > > On Fri 22-06-18 17:33:12, 禹舟键 wrote: > > Hi Michal > > > diff --git a/include/linux/oom.h b/include/linux/oom.h > > > index 6adac113e96d..5bed78d4bfb8 100644 > > > --- a/include/linux/oom.h > >

Re: [PATCH v11 1/2] Refactor part of the oom report in dump_header

Hi Michal cpuset_print_current_mems_allowed is also invoked by warn_alloc(page_alloc.c). So, can I remove the current->comm output in the pr_info ? diff --git a/kernel/cgroup/cpuset.c b/kernel/cgroup/cpuset.c index d8b12e0d39cd..09b8ef6186c6 100644 --- a/kernel/cgroup/cpuset.c +++

[PATCH v7 1/2] Add an array of const char and enum oom_constraint in memcontrol.h

From: yuzhoujian This patch will make some preparation for the follow-up patch: Refactor part of the oom report in dump_header. It puts enum oom_constraint in memcontrol.h and adds an array of const char for each constraint. Signed-off-by: yuzhoujian --- include/linux/memcontrol.h | 14

Re: [PATCH v7 2/2] Refactor part of the oom report in dump_header

Hi Mike > Please keep the brief description of the function actually brief and move the > detailed explanation after the parameters description. Thanks for your advice. > The allocation constraint is detected by the dump_header() callers, why not > just use it here? David suggest that

Re: [PATCH v7 2/2] Refactor part of the oom report in dump_header

f it is 0. origin_memcg_name will be "(null)". I've tested !memcg OOM case with CONFIG_MEMCG and !CONFIG_MEMCG, and found nothing wrong. Thanks Wind 禹舟键 于2018年6月4日周一 上午9:58写道： > > Hi Mike > > Please keep the brief description of the function actually brief and move > > the deta

Re: [PATCH v7 2/2] Refactor part of the oom report in dump_header

Hi Mike > My question was why do you call to alloc_constrained in the dump_header() >function rather than pass the constraint that was detected a bit earlier to >that function? Ok, I will add a new parameter in the dump_header. Thank you.

Re: [PATCH v7 2/2] Refactor part of the oom report in dump_header

Hi Tetsuo I know what you mean. Actully I refer to the code for kernel version: 3.10.0-514. I think I can just use an array of type char, rather than static char. Is it right? Thanks

Re: [PATCH v7 2/2] Refactor part of the oom report in dump_header

Hi Michal > I have earlier suggested that you split this into two parts. One to add > the missing information and the later to convert it to a single printk > output. I'm sorry I do not get your point. What do you mean the missing information? > but it still really begs an example why we

Re: [PATCH v7 2/2] Refactor part of the oom report in dump_header

Hi Michal I will add the missing information in the cover-letter. > That being said, I am ready to ack a patch which adds the memcg of the > oom victim. I will not ack (nor nack) the patch which turns it into a > single print because I am not sure the benefit is really worth it. Maybe > others

Re: [LKP] [mm, oom] c1e4c54f9c: BUG:KASAN:null-ptr-deref_in_d

Hi Michal and David, AFAICS, the null pointer is the task_struct of p in the dump_header. Why don't we just add a if before printing the victim task's informaiton. diff --git a/mm/oom_kill.c b/mm/oom_kill.c --- a/mm/oom_kill.c +++ b/mm/oom_kill.c @@ -438,14 +438,6 @@ static void

Re: [LKP] [mm, oom] c1e4c54f9c: BUG:KASAN:null-ptr-deref_in_d

Hi Michal Sorry, I cannot open the link you shared.

Re: [PATCH] sched/debug: Show intergroup and hierarchy sum wait time of a task group

PING 禹舟键 于2019年2月12日周二 上午11:14写道： > > Hi, Peter > I think hierarchy wait time for task groups is worth accounting > despite with a little extra overhead. Because we can evaluate task > groups' condition with a more direct metric. We cannot get the real > situation just with so

Re: [PATCH] doc: cgroup: correct the wrong information about measure of memory pressure

Hi TeJun I've built the 5.0.0-rc6 kernel with psi option, but I cannot find any cgroup.controllers when I mounted cgroup2. [root@bogon /]# uname -r [root@bogon /]# 5.0.0-rc6+ [root@bogon /]# mount -t cgroup2 none cgroup2/ [root@bogon /]# cat cgroup2/cgroup.controllers [root@bogon /] [root@bogon

Re: [PATCH] sched/debug: Show intergroup and hierarchy sum wait time of a task group

Hi, Peter I think hierarchy wait time for task groups is worth accounting despite with a little extra overhead. Because we can evaluate task groups' condition with a more direct metric. We cannot get the real situation just with some general metrics, like idle or loadavg, since their value is

Re: [PATCH] sched/debug: Show intergroup and hierarchy sum wait time of a task group

PING 禹舟键 于2019年2月19日周二 上午10:15写道： > > PING > > 禹舟键 于2019年2月12日周二 上午11:14写道： > > > > Hi, Peter > > I think hierarchy wait time for task groups is worth accounting > > despite with a little extra overhead. Because we can evaluate task > > groups' cond

Re: [PATCH v11 1/2] Refactor part of the oom report in dump_header

Hi Andy The const char array need to be used by the new func mem_cgroup_print_oom_context and some funcs in oom_kill.c in the second patch. Thanks > > On Sat, Jun 30, 2018 at 7:38 PM, wrote: > > From: yuzhoujian > > > > The current system wide oom report prints information about the victim >

Re: [PATCH v11 1/2] Refactor part of the oom report in dump_header

Hi Michal and Andy The enum oom_constraint will be added in the struct oom_control. So I still think I should define it in oom.h. Michal Hocko 于2018年7月4日周三 下午4:17写道： > > On Wed 04-07-18 10:25:30, 禹舟键 wrote: > > Hi Andy > > The const char array need to be us

Re: [PATCH v14 1/2] Reorganize the oom report in dump_header

Hi Michal OK, thanks. Is there any problems for V14? Thanks

Re: [PATCH v13 2/2] Add oom victim's memcg to the oom context information

Hi David Could I use use plain old %d? Just like this, pr_cont(",task=%s,pid=%d,uid=%d\n", p->comm, p->pid, from_kuid(_user_ns, task_uid(p))); Thanks

Re: [PATCH v7 2/2] Refactor part of the oom report in dump_header

Hi Mike > My question was why do you call to alloc_constrained in the dump_header() > function rather than pass the constraint that was detected a bit earlier to > that function? dump_header will be called by three functions: oom_kill_process, check_panic_on_oom, out_of_memory. We can get the