[lkml]   [1998]   [Oct]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [patch] my latest oom stuff
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. |
| Scouting Vries cubscout leader. |

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:45    [W:0.069 / U:0.484 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site