>It also introduces a new one: having kswapd stop when
>try_to_free_page() fails. When try_to_free_page() fails,
Tell me how can kswapd free memory if try_to_free_page() fail! If
try_to_free_page() fails it means that we really have not enough memory
and we _must_ stop. If we continue to run do_try_to_free_page() when we
are out of memory we cause kswapd to run for 2 sec continuosly forever. A
process has to run to have a chance to generate a page fault and to be
killed. If kswapd eat all the CPU all the time other processes can' t run.
Please try swapoff -a and _then_ run leak. Then apply my patch and run
leak.
BTW the leak.c I developed to test the OOM is this:
main()
{
char *p[20];
int i, j;
for (j=0; j<20; j++)
{
p[j] = (char *) malloc(1000000);
}
for (;;)
for (j=0; j<20; j++)
{
for (i=0; i<1000000; i++)
p[j][i] = 0;
}
}
I run many many copies of this program in background to test my patch.
>that could also mean that all pages have been touched
>since we ran last -- that just means we'll have to run
>again; stopping will make things worse.
Try again I can' t understand due English.
>> If you want to use an OOM killer to choice which process to kill
>> when the system is OOM you first need to know _when_ the system is
>> OOM. Right now the kernel is not able to detect when the system is
>> OOM after a page fault because __get_free_pages() never returns NULL
>> _and_ because kswapd runs forever. My patch fix all such bugs. If
>> you want to use your OOM killer you have simply to change the
>> force_sig() in the swapin and anonymous page fault with something
>> like your kill_the_best_process() (aka OOM_killer()).
>
>Your patch doesn't really fix the bug. It makes sure that
>kswapd has complete failures more often, and this can be
>considered a bad thing instead of something nice.
For what I understand from the code there is a simple function called
do_try_to_free_page(). This function when called must try to free a page.
When this function fails it means that there isn' t a freeable page. If
there isn' t a freeble page how can kswapd free memory even if run all the
time?
Ok I can agree that we could wait two/three consecutive fail of
do_try_to_free_page() (for increase the pressure, even if returning at the
first fail seems to work just fine) before put kswapd to sleep but this
doesn' t change my point.
>about detecting OOM yet. (the one problem is the legitimate
>case where ram and swap are full but we have a lot of swap cache)
If there' s a lot of swap cache you can run shrink_mmap() or follow the
swap cache list and checking if the swap cache page->count is 1, in such
case you can delete_from_swap_cache(page) (you can hack my
shrink_swap_cache() to do this).
>> And btw I don' t like an OOM killer that choice wich process to kill
>> when the system is OOM. The only justice I can think is to kill
>> _the_ current process: the process that has requested memory via a
>> page fault if __get_free_pages() returned NULL (and if you are using
>> a kernel daemon you can' t know which is that process btw).
>
>It is not always right to kill the current process. It could
>be X or you two-week-old simulation that just needs a few
>extra kilobytes do format it's OUTPUT -- bang, there go two
>weeks of calculations...
Agreed. But if the current process is not iopl I think we should kill the
process that has generated the page fault when __get_free_pages() returned
NULL. You simply need to change force_sig() in mm/*.c with a
change_which_process_to_kill() to do that.
>And all just because a newly started Netscape allocated all
>but the last few kilobytes of memory. In that case, it might
>be _far_ better to kill Netscape or something else that's both
>new and large.
No. Wrong. If netscape is swapped out and sleeping, killing Netscape would
be a wrong choice. Eventually it could be tunable but sure killing
Netscape if it' s sleeping it' s a wrong default I think.
The _only_ way an OOM killer could be useful is to avoid killing of X.
>Killing the current process equals killing a random process;
>most people don't like this, especially not when it is the X
>server. This means that quite a lot of people do need an OOM
>killer.
For X OK.
>With your patch the system will run out of memory more often,
>that is a very bad thing to happen.
Can you reproduce a condition where without my patch 2.1.124 doesn' t
deadlock and instead 2.1.124 + my patch fail?
And Linux must go OOM when there' s no memory!
>Killing the machine is easy with your patch: if it happens
>to be X that needs to swap something in when the memory is
>gone, X will be killed and the machine will be dead (at least
>the console will).
Probably you should understand the difference between kernel and userland
issues.
If you won' t able to understand yourself ask me and I' ll hack for you a
svga application to put the card in graphics mode and forking many many
times running my leak program. I' ll see if your OOM killer will be able
to put the console in text mode again.
>My patch never kills the X server or any other IOPL process.
I agree it' s a good thing to have a way to learn to the kernel to kill a
process only as last resort, but note that iopl is not enough and we
should have another way to detect the X server since XFreeFB should not
run in iopl anymore. So I don' t think we should put an OOM killer in the
stock 2.2 (we should just be in code freezee (so think at feature
freezee...)).
Andrea[s] Arcangeli
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/