[lkml]   [2009]   [Aug]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 13/12] ksm: fix munlock during exit_mmap deadlock
Hugh Dickins wrote:
> On Wed, 26 Aug 2009, Andrea Arcangeli wrote:
>> All is left to address is to teach page_alloc.c that the mm is going
>> away in a second patch. That might also help when it's aio triggering
>> gup page allocations or other kernel threads with use_mm just like ksm
>> and the oom killer selected those "mm" for release.
>> Having ksm using use_mm before triggering the handle_mm_fault (so
>> tsk->mm points to the mm of the task) and adding a MMF_MEMDIE to
>> mm->flags checked by page_alloc would work just fine and should solve
>> the double task killed... but then I'm unsure.. this is just the first
>> idea I had.
> Yes, I began to have thoughts along those lines too as I was writing
> my reply. It is a different angle on the problem, I hadn't looked at
> it that way before, and it does seem worth pursuing. MMF_MEMDIE, yes,
> that might be useful. But KSM_RUN_UNMERGE wouldn't be able to use_mm
> since it's coming from a normal user process - perhaps it should be a
> kill-me-first like swapoff via PF_SWAPOFF.
> Hugh
About the KSM case:
The oom should work on problomatic processes, such that allocate big
amount of memory.
But then as we now plane it to be, what might be a just fine application
that used ksm and told it to stop merge it pages, might be what
considered "bad application that need to be killed"

Is this what we really want?

But before getting into this, why is it so important to break the ksm
pages when madvise(UNMERGEABLE) get called?

When thinking about it, lets say I want to use ksm to scan 2
applications and merged their STATIC identical data, and then i want to
stop scanning them after i know ksm merged the pages, as soon as i will
try to unregister this 2 applications ksm will unmerge the pages, so we
dont allow such thing for the user (we can tell him ofcurse for such
case to use normal way of sharing, so this isnt a really strong case for

 \ /
  Last update: 2009-08-26 22:51    [W:0.090 / U:4.824 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site