Messages in this thread | | | Date | Mon, 9 Apr 2012 17:04:01 -0700 (PDT) | From | David Rientjes <> | Subject | Re: v3.4-rc2 out-of-memory problems (was Re: 3.4-rc1 sticks-and-crashs) |
| |
On Mon, 9 Apr 2012, Linus Torvalds wrote:
> > You could that if you also turned the check for "ret == NOTIFY_OK" in > > profile_handoff_task() into "ret & NOTIFY_OK" in your patch, otherwise you > > get a double free from __put_task_struct() and oprofile. > > Why? NOTIFY_DONE is zero. >
Oops, right.
> > (1) fix the lowmemorykiller so it doesn't need to use these notifiers at > > all, which isn't difficult, for 3.4, then > > I do think that that makes sense. Fixing people to not use notifiers > is always a good idea. Why would anybody sane even care about the > process going away anyway? If some lowmemorykiller decides to kill off > a process that no longer exists, kill() should happily return ENOSRCH, > and we're all good >
It's apparently waiting for a killed thread to exit before selecting another victim or the one second timeout expires. (And you only get to prevent needless kills if you have CONFIG_PROFILING, otherwise it doesn't care.)
> At the same time, the *only* user of that stupid handoff thing is > oprofile, afaik, and if we use a refcount, why the hell doesn't > oprofile just use a refcount to begin with, instead of using that > notifier?: IOW, *both* users of the notifier seem to be just retarded. >
Agreed and since the current implementation relies on CONFIG_PROFILING I think it's safe to remove the notifier and add a hook only for oprofile so it can do free_task() when it wants to. No refcounting required.
I've already proposed a patch that removes the notifier for lowmemorykiller with the added benefit that it doesn't rely on CONFIG_PROFILING at all. If that's merged for 3.4, I'll remove the task handoff callchain entirely for 3.5 since oprofile is the only user. | |