Messages in this thread | | | Date | Sat, 7 Apr 2012 00:53:55 +0530 | Subject | Re: [PATCH 04/19 v2] openrisc/mm/fault.c: Port OOM changes to do_page_fault | From | Kautuk Consul <> |
| |
On Fri, Apr 6, 2012 at 10:11 PM, Jonas Bonn <jonas@southpole.se> wrote: > Hi Kautuk, > > OK, I had a look at this patch and I think it's fine. This is a little > over my head so I'm just going to take you word for it doing the right > thing... it doesn't seem to fundamentally break anything in any case. > stress_32k runs and the OOM killer takes it down nicely. >
Its just something that I was investigating and testing for ARM and MIPS, so its just a little "involved" thats all.
In a nutshell: I observed that process threads used to get stuck via the handle_mm_fault ---> filemap_fault() route inside filesystems in the __alloc_pages_slowpath() loop in mm/page-alloc.c due to non-availability of physical memory. Since they keep looping within the __alloc_pages_slowpath(), they are not killed despite getting a SIGKILL as they don't return back to the usermode and keep spinning. Also, since the mmap_sem is taken, other processes trying to do allocate memory sleep indefinitely over the mmap_sem. So, the process hangs instead of getting killed and releasing its pages.
This patch gives a chance for filemap_fault() to release the mmap_sem in low memory situations so that the thread can return back to the page-fault handling code to handle the signal and quit gracefully.
But, the best thing will be to have a low memory killer such as the one that the Android people are working on as this hang/livelock situation can still happen even with this patch file. So this patch file just tries to improve the reliability of OOM killer in extreme memory pressure situation, thats all.
> I'll paste the output from running stress_32k (here called testkautuk) > here in case you haven't seen how elegant the oom-killer output is on > openrisc... > > Thanks for the patch. > > Acked-by: Jonas Bonn <jonas@southpole.se>
Thanks for the ACK ! Since I don't have any branch of my own, can you please apply this to your branch ? Or else, I'll have to ask someone else to apply this on their branches and thats a relatively longer process. :-(
> > /Jonas >
And thanks for pasting the output.. it looks good ! :-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |