Resource allocation

Francois-Rene Rideau rideau@clipper
Mon, 5 Dec 94 13:07:50 MET


[What discussion thread should this be on ?]
IMPORTANT: memory allocation strategy.

   A major point in an OS is the resource allocation and quotas system used:
there *must* be a mechanism to eliminate objects that go wild and claim
ever more memory; but we must still allow truely big processes that take
up a lot of memory anyway (e.g. big database server).


  In un*x-like coarse-grained systems, it's easy to maintain a count of
resources used by each user and each process, because there's so few
interactions and everything is centralized.
  But we want no more such centralization, and free interaction. Then, how
to measure that some object is a crazy one, while another one is serious ?
If I'm out of memory, will I kill that very small object, that is the
result of very long computations (actually, the nth child of a recursively
self-spawing object that fills memory at high-speed), or this huge object
that's seldom active, and just lies there (actually a very important net
server) ?
  And what of the "witty memory grabber" program, that *slowly* accumulates
a list of all available objects it can find, so that it forces the system
to remember them, even though they are not otherwise needed anymore ?
  There *can't* be some unique heuristic that would be based only on actual
resources used to determine if a program using some resource is actually
useful.


  If we are to remember the space and resources recursively occupied by every
sample (possible tiny) object, this means any resource (dis)allocation will
have to be bounced to all the objects above or below the allocating one ! This
also mean no simple recursive pointers, and no simple object sharing ! This is
not feasible. Then what ?
  Maybe each program should be declared either with some limitations that
it must respect unless some authorized user states otherwise. Tiny objects
would be allocated inside coarse grained heaps. So here is the policy I
propose:
* there are service/resource providers
* there are service/resource multiplexers/demultiplexers and mux
  mergers/splitters, that behave like coarse grained objects, with heavy
  resource allocation mechanism.
* tiny objects work through these mux objects, they are automatically copied
 between pools.

--    ,        	                                ,           _ v    ~  ^  --
-- Fare -- rideau@clipper.ens.fr -- Francois-Rene Rideau -- +)ang-Vu Ban --
--                                      '                   / .          --
MOOSE project member. OSL developper.                     |   |   /
Dreams about The Universal (Distributed) Database.       --- --- //
Snail mail: 6, rue Augustin Thierry 75019 PARIS FRANCE   /|\ /|\ //
Phone: 033 1 42026735                                    /|\ /|\ /