Messages in this thread | | | From | KOSAKI Motohiro <> | Subject | Re: [resend][PATCH 4/4] oom: don't ignore rss in nascent mm | Date | Wed, 24 Nov 2010 09:24:39 +0900 (JST) |
| |
Hi
> On 10/25, KOSAKI Motohiro wrote: > > > > Because execve() makes new mm struct and setup stack and > > copy argv. It mean the task have two mm while execve() temporary. > > Unfortunately this nascent mm is not pointed any tasks, then > > OOM-killer can't detect this memory usage. therefore OOM-killer > > may kill incorrect task. > > > > Thus, this patch added signal->in_exec_mm member and track > > nascent mm usage. > > Stupid question. > > Can't we just account these allocations in the old -mm temporary? > > IOW. Please look at the "patch" below. It is of course incomplete > and wrong (to the point inc_mm_counter() is not safe without > SPLIT_RSS_COUNTING), and copy_strings/flush_old_exec are not the > best places to play with mm-counters, just to explain what I mean. > > It is very simple. copy_strings() increments MM_ANONPAGES every > time we add a new page into bprm->vma. This makes this memory > visible to select_bad_process(). > > When exec changes ->mm (or if it fails), we change MM_ANONPAGES > counter back. > > Most probably I missed something, but what do you think?
Because, If the pages of argv is swapping out when processing execve, This accouing doesn't work.
Of cource, changing swapping-out logic is one of way. But I did hope no VM core logic change. taking implict mlocking argv area during execve is also one of option. But I did think implicit mlocking is more risky.
Is this enough explanation? Please don't hesitate say "no". If people don't like my approach, I don't hesitate change my thinking.
Thanks.
| |