Re: [patch] my latest oom stuff

Rik van Riel (H.H.vanRiel@phys.uu.nl)
Sun, 25 Oct 1998 20:32:48 +0100 (CET)


On Sun, 25 Oct 1998, Andrea Arcangeli wrote:

> 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().

Yes, this is an old version. I know I should fix that problem,
but with you bashing my patch like you did last week, and the
amount of positive feedback I got on my scheduling patch you
will understand that the scheduler patch got a bit of precedence.

> >+ 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.

The whole idea about my patch is that
current != 'guilty'.

> >+ /* 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?

OK, lets cut it out...

Rik -- typing slowly because my kbd is dvorak since sun 19:40...
+-------------------------------------------------------------------+
| Linux memory management tour guide. H.H.vanRiel@phys.uu.nl |
| Scouting Vries cubscout leader. http://www.phys.uu.nl/~riel/ |
+-------------------------------------------------------------------+

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