Adam writes:
>>> Well why not to reserve memory for root usage only, as this is
>>> done with space on the root file system ?
>>
>> That means no overcommitment of memory. It's a solution, but you'll need
>> _huge_ swapspaces just for making sure each time emacs spawns an ls the
>> space for the 4 500Kb files it has open is available.
>
> uh, when you are out of memory, you don't start emacs to fix the problem.
No, you don't get it. Just to run "ls" from emacs you will need many
extra megabytes of swap space. Unlike UNIX and BSD users, Linux users
have long taken advantage of the ability to operate without very much
swap space at all. Some people don't even have swap space.
> And on interesting note, had we cast current memory situation on disk
> space it would be something like this. "Ops, we just ran out of disk
> space, let's kernel delete some files so that we can continue. How
> about /sbin/init." How many people would find that acceptable?
No, that isn't right. Processes (files) that don't grab any more
memory (disk space) don't get killed (deleted).
Current policy is like this:
You have a file with holes or other compression. When you try to
write to this, the file gets removed.
Rik's OOM patch:
You have a file with holes or other compression. When you try to
write to this, the kernel searches for junk files. It finds core
files, /tmp files, emacs backup files, *.o files...
(hmmm, I think something bad does happen when you mmap a sparse
file and write to it while the disk is full... should fix that too,
but unlike OOM this ought to be 90% userspace)
> I don't mind have reseverd %5 of ram so that I can su and kill whatever
> offending process is. In fact I often run in one of windows 'sash' just
> for cases like this one. I also often have serial console with root on
> it already which comes hand too.
>
> All I need is kernel to suspend the programs which needs memory
> until *I* can figure out what's wrong and kill what *I* think is
> offending process.
You sit at a serial console 24x7 waiting for an OOM condition?
For most people, servers (including X) just die randomly and there
is no way out besides a reboot.
-
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/
This archive was generated by hypermail 2b29 : Wed Mar 15 2000 - 21:00:22 EST