Messages in this thread | | | Date | Mon, 7 Aug 2023 10:21:09 +0800 | Subject | Re: [RFC PATCH 1/2] mm, oom: Introduce bpf_select_task | From | Chuyi Zhou <> |
| |
在 2023/8/4 21:34, Michal Hocko 写道: > On Fri 04-08-23 21:15:57, Chuyi Zhou wrote: > [...] >>> + switch (bpf_oom_evaluate_task(task, oc, &points)) { >>> + case -EOPNOTSUPP: break; /* No BPF policy */ >>> + case -EBUSY: goto abort; /* abort search process */ >>> + case 0: goto next; /* ignore process */ >>> + default: goto select; /* note the task */ >>> + } >> >> Why we need to change the *points* value if we do not care about oom_badness >> ? Is it used to record some state? If so, we could record it through bpf >> map. > > Strictly speaking we do not need to. That would require BPF to keep the > state internally. Many will do I suppose but we have to keep track of > the victim so that the oom killer knows what to kill so I thought that > it doesn't hurt to keep track of an abstract concept of points as well. > If you think this is not needed then oc->points could be always 0 for > bpf selected victims. The value is not used anyway in the proposed > scheme. > > Btw. we will need another hook or metadata for the reporting side of > things. Generally dump_header() to know what has been the selection > policy. > OK. Maybe a integer like policy_type is enough to distinguish different policies and the default method is zero. Or we can let BPF return a string like policy_name.
Which one should I start implementing in next version? Do you have a better idea?
Thanks.
| |