[lkml]   [2002]   [Jul]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] strict VM overcommit

On Sun, 21 Jul 2002, Szakacsits Szabolcs wrote:
> What about the many hundred counter-examples

These cases are different.

> (e.g. umount gives EBUSY,

Simply because you _will_ lose data if you umount a device that's being
scribbled on.

> kill can't kill processes in uninterruptible sleep

Because the uninterruptible sleep means the process is waiting for data.
If you destroy the process and kill an interrupt handler, you _will_

> , etc, etc)? Why the system knows better then admin in these cases? Why
> just don't destroy the data, crash the system as you suggest in your
> case?

This case is different. If you swapoff /dev/scsi/path/to/dead/disk, your
system will likely live on. Possibly you'll have some tasks killed, but
we're well up.

Alan was referring to cases where it's unlikely that we die of it, you're
referring to cases where it's clear that the system won't get through.

(Use if you can't decode)
Version: 3.12
GCS/E/G/S/AT d- s++:-- a? C++$ ULAVHI++++$ P++$ L++++(+++++)$ E W-$
N--- o? K? w-- O- M V$ PS+ PE- Y- PGP+ t+ 5+ X+ R- !tv b++ DI? !D G
e++++ h* r--- y-

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

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