lkml.org 
[lkml]   [2002]   [Jul]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] strict VM overcommit

On 21 Jul 2002, Alan Cox wrote:
> On Sun, 2002-07-21 at 16:23, Szakacsits Szabolcs wrote:
> > What about the many hundred counter-examples (e.g. umount gives EBUSY,
>
> umount -f.

The wasn't the question. *Why* umount (without -f) knows better then
admin? You answered *how* unconditionally umount.

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

> very different from stopping a user doing something it can handle
> perfectly well.

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?

Szaka

-
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:27    [W:0.398 / U:0.008 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site