Re: [patch] my latest oom stuff

Andrea Arcangeli (andrea@e-mind.com)
Sun, 25 Oct 1998 19:12:20 +0100 (CET)


I think that if you would recall the oom killer from the right place you
could speak about inclusion. The _only_ point of an OOM killer is to
replace the force_sig() from mm/*.c with oom_kill().

If you leave somewhere a force_sig() you prove that the whole design of
your OOM killer patch is completly bogus (I am not talking about the
heuristic of choose the right process to kill inside oom_kill()). It
proves that the current mm is so unbalanced that you have no one risk to
leave the force_sig() there.

>+ /*
>+ * If kswapd is looping, the below is needed. If we're just
>+ * thrashing, it can't hurt since p will be thrashing too...
>+ */
>+ p->rt_priority = 1000;
>+ p->policy = SCHED_FIFO;
>+ force_sig(SIGKILL, p);

It' s nice to see that you understand that the system is so deadlocked
that the only chance to allow a process to be scheduled() is to put in RT.

>+extern int out_of_memory(void);
>+extern void oom_kill(void);
^^^^^^^^^^^^^^ This is improvable a lot too, since in the
right way we could have info about the task that caused the page fault.

>+ /* Don't allow a mode change when page cache or buffermem is over max */
>+ if (((buffermem >> PAGE_SHIFT) * 100 < buffer_mem.max_percent * num_physpages) &&
>+ (page_cache_size * 100 < page_cache.max_percent * num_physpages))
>+ state = 1;

I don' t agree with this. What if all pages are shared for example?

Andrea 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/