Messages in this thread | | | From | KOSAKI Motohiro <> | Subject | Re: [RFC PATCH 2/2] Don't continue reclaim if the system have plenty free memory | Date | Thu, 9 Jul 2009 14:08:38 +0900 (JST) |
| |
> Hi, Kosaki. > > On Tue, Jul 7, 2009 at 6:48 PM, KOSAKI > Motohiro<kosaki.motohiro@jp.fujitsu.com> wrote: > > Subject: [PATCH] Don't continue reclaim if the system have plenty free memory > > > > On concurrent reclaim situation, if one reclaimer makes OOM, maybe other > > reclaimer can stop reclaim because OOM killer makes enough free memory. > > > > But current kernel doesn't have its logic. Then, we can face following accidental > > 2nd OOM scenario. > > > > 1. System memory is used by only one big process. > > 2. memory shortage occur and concurrent reclaim start. > > 3. One reclaimer makes OOM and OOM killer kill above big process. > > 4. Almost reclaimable page will be freed. > > 5. Another reclaimer can't find any reclaimable page because those pages are > > ? already freed. > > 6. Then, system makes accidental and unnecessary 2nd OOM killer. > > > > Did you see the this situation ? > Why I ask is that we have already a routine for preventing parallel > OOM killing in __alloc_pages_may_oom. > > Couldn't it protect your scenario ?
Can you please see actual code of this patch? Those two patches fix different problem.
1/2 fixes the issue of that concurrent direct reclaimer makes too many isolated pages. 2/2 fixes the issue of that reclaim and exit race makes accidental oom.
> If it can't, Could you explain the scenario in more detail ?
__alloc_pages_may_oom() check don't effect the threads of already entered reclaim. it's obvious.
| |