mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Arve Hjønnevåg" <arve@android.com>
To: Greg KH <greg@kroah.com>
Cc: David Rientjes <rientjes@google.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Nick Piggin <npiggin@suse.de>, San Mehat <san@android.com>,
	linux-kernel@vger.kernel.org, Greg KH <gregkh@suse.de>
Subject: Re: [patch 1/5] oom: cleanup android low memory killer
Date: Mon, 4 May 2009 16:36:47 -0700	[thread overview]
Message-ID: <d6200be20905041636v4a1743e1mdbb5af53621e9cb3@mail.gmail.com> (raw)
In-Reply-To: <20090504231626.GA27123@kroah.com>

On Mon, May 4, 2009 at 4:16 PM, Greg KH <greg@kroah.com> wrote:
> On Mon, May 04, 2009 at 04:12:57PM -0700, David Rientjes wrote:
>> On Mon, 4 May 2009, Greg KH wrote:
>>
>> > > This patch in the series is really more of a convenience than anything
>> > > else since it doesn't change anything functionally.  I had to modify the
>> > > lowmemorykiller later because there's a potential for a NULL pointer from
>> > > dereferencing p->mm without holding task_lock(p) and also because I moved
>> > > oomkilladj from struct task_struct to struct mm_struct.
>> >
>> > Is this still the case on top of Arve's changes?
>> >
>>
>> Yeah, the first of two patches Arve just sent is broken:
>
> Ok, care to work with Arve to come up with a series that both of you
> agree will work properly?

Yes, that patch only addresses the issues brought up last time this
driver was discussed.

>
>> > Right now, people are still arguing that the android low memory driver
>> > is not needed, but something is, yet no one has proposed a viable
>> > solution for all parties :(
>> >
>>
>> There was an interest in a low mem userspace notifier that applications
>> can poll() on at configurable low mem levels to react accordingly.  This
>> would probably address the problem that the Android team is trying to fix.
>
> Yes, I think it would.
>

Possibly, but waking up a user space code when running out of memory
may need even more memory to be freed.

>> Regardless, my patchset includes two fixes for current bugs in the oom
>> killer: a possible NULL pointer when /proc/sys/vm/oom_dump_tasks is
>> enabled and a possible livelock when killing a task that shares memory
>> with an OOM_DISABLE task.  I'm not really interested in seeing who can get
>> their patches into the staging tree first, I'm more concerned about fixing
>> the oom killer.
>
> Agreed, working with Arve on this would be most appreciated.

I have no problem with the patch that adds task_lock and I can add the
same change myself if you prefer, but the code cleanup patch will
cause unnecessary conflicts for us.

-- 
Arve Hjønnevåg

  reply	other threads:[~2009-05-04 23:37 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-04 16:35 David Rientjes
2009-05-04 16:35 ` [patch 2/5] oom: fix possible android low memory killer NULL pointer David Rientjes
2009-05-04 16:35 ` [patch 3/5] oom: fix possible oom_dump_tasks " David Rientjes
2009-05-04 16:35 ` [patch 4/5] oom: move oom_adj value from task_struct to mm_struct David Rientjes
2009-05-04 16:35 ` [patch 5/5] oom: prevent possible OOM_DISABLE livelock David Rientjes
2009-05-04 21:48 ` [patch 1/5] oom: cleanup android low memory killer Arve Hjønnevåg
2009-05-04 22:09   ` Greg KH
2009-05-04 22:24     ` [PATCH 1/2] lowmemorykiller: Only iterate over process list when needed Arve Hjønnevåg
2009-05-04 22:24       ` [PATCH 2/2] lowmemorykiller: Don't count free space unless it meets the specified limit by itself Arve Hjønnevåg
2009-05-04 22:35     ` [patch 1/5] oom: cleanup android low memory killer David Rientjes
2009-05-04 22:59       ` Greg KH
2009-05-04 23:12         ` David Rientjes
2009-05-04 23:16           ` Greg KH
2009-05-04 23:36             ` Arve Hjønnevåg [this message]
2009-05-04 23:59             ` David Rientjes
2009-05-04 23:32           ` Rik van Riel
2009-05-11 19:44             ` David Rientjes
2009-05-14 12:23               ` KOSAKI Motohiro

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d6200be20905041636v4a1743e1mdbb5af53621e9cb3@mail.gmail.com \
    --to=arve@android.com \
    --cc=akpm@linux-foundation.org \
    --cc=greg@kroah.com \
    --cc=gregkh@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=npiggin@suse.de \
    --cc=rientjes@google.com \
    --cc=san@android.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®