Re: Avoiding OOM on overcommit...?

From: Jesse Pollard (pollard@tomcat.admin.navo.hpc.mil)
Date: Mon Mar 27 2000 - 10:01:27 EST


Marco Colombo <marco@esi.it>
> On Sun, 26 Mar 2000, Linda Walsh wrote:
>
> > David Whysong wrote:
> > > If you run out of a resource, the system should not crash. The kernel just
> > > has to free up the resource. A convenient way of doing that is to kill a
> > > user process.
> > ---
> > Then you have violated the integrity of the user-process space.
> > Tell me, which processes are killed when the system runs out file descriptors?
> > How about processes? Disk space? Why are you treating memory differently?
>
> Because overcommitting swap space is possible and it works (higher
> system throughput, on average case).
>
> Please explain how you'd implement 'overcommitting' of PIDs, or open files.

Silly:
        pids - allocate one page to the pid table - tell kernel there
                are an infinite number of pids, but only allocate one page -
                why allocate more, they don't all get used....
        files - don't allocate a file table, do just like above with pids...

BTW, pids are overcommited. Originally they were equivalent to "slot". The
above discription for pids also applies to slots.

> And BTW, the system is not 'overcommitting' anything. The kernel is just
> extending VA space of a process. It's giving you more "names". It's not
> giving you any object. VA space is not "memory".

To the user porcess it is memory. They are pages of real storage locations.
NOT the same as "names".

> Offsets in a file are just "names". That's why you can write one block
> at 1GB offset, without allocating 1GB of disk space. Is this overcommiting
> of FS space? Just because the system lets you create a file which is
> 1GB in *size* (but not in disk usage), it doesn't mean you have 1GB of
> free disk space. And just because the system lets you malloc(1GB) of
> address space, and even lets you successfully write at 1GB-1 offset,
> it doesn't mean there's 1GB of free RAM or swap. Why are you treating
> memory differently from disk space?

It isn't being treated differently. A sparce file is still limited by
the users disk quota (which measures what is actually used...) When the
user exceeds quota the user is aborted. Just because one user reached quota
limit, is no reason to abort all users of the disk, or even to abort a
random user....

If there are no quotas on disk then the last process that attempts a write
will get aborted - the random process... This is the same as for memory without
quotas.

Disk quotas serve the same purpose that memory quotas do. They provide
for equitibly sharing access while providing security to the space assigned
can be used by the user/process that it was assigned to.

-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil

Any opinions expressed are solely my own.

-
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 : Fri Mar 31 2000 - 21:00:19 EST