lkml.org 
[lkml]   [2002]   [Jul]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH] strict VM overcommit
From
Date
On Mon, 2002-07-22 at 09:08, Szakacsits Szabolcs wrote:
> > > kill can't kill processes in uninterruptible sleep, etc, etc)? Why the
> > In these cases the kernel infrastructure doesn't support the ability to
> > recover from such a state,
>
> You again anwered else but ironically you just rebute yourself that
> there are cases when the system knows better then the admin.

And purists consider those flaws

> What the patch claims is no OOM. In the swapoff case potentially there
> are OOM's. This is called bug (the feature not follows the behavior
> what it specified when admin turned it on). Why do you call this bug
> perfectly handled case? What differentiate this case from all other
> when the system knows better not to destroy your data without at least
> a "force" operation for example?

Lets put this bluntly. Your swapdisk is losing sectors left right and
centre. You propose a system where the kernel says "sorry might cause an
OOM" and I lose everything as the disk goes down. Letting the admin set
policy means I can swapoff, maybe lose a program or two to OOM but not
lose the entire system in the process.

Its quite clear that being able to override the kernels assumptions
about what is right are sensible. It always has been

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

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