Re: Memory management

[Marcus Brinkmann]

Neal is the memory man, but I'll try to answer.

At Sun, 18 Apr 2004 23:34:01 +0200,
Tomasz Gajewski wrote:
> 5.4.1 Guaranteed Frames and Extra Frames
[...]
> 5.7 The Memory Policy Server
[...]

> Both fragments refer to releasing memory by the task and in both cases
> the task is given some amount of "time" to do the requested work.
> 
> I assume that "time" cannot mean the clock time because that would
> allow the possibility that under high load task would not get a
> chance to do requested work.

We don't have an answer for how much time is enough, and how the time
should be measured.  Basically, we are putting off the answer
indefinitely, because it is not very critical.  Just whatever is
"enough" is good enough.
 
> So the "time" should be defined in terms of resources given to task
> rather than a clock time. I think that processor time utilized by a
> task could be a good solution but physical memory server and memory
> policy server don't have information about it. It means that they
> would have to ask for this information server which does accounting
> information (task server if I remember correctly).

Yes.  However, processing time is also unreasonable.  Consider a low
priority task, which never is scheduled because there are always
higher priority tasks.  In this case, the low priority task could sit
on its memory indefinitely without punishment.  Should the task be
reliefed from giving memory back because it didn't have a fair chance
to make a selection?  That sounds wrong to me.  The only alternative
is to take back memory forcefully if you are never scheduled, but that
also seems to be undesirable to me.

However, consider the following attack: You allocate a lot of memory
at a time where memory is not scarce.  Then you depress your priority.
You also start another task which busy loops at a higher priority than
the depressed one.  This needs to be prevented of course.

So, processing time does not seem to be the answer.

One possibility might be to take an upper estimate based on system
load (number of threads running).  Anything that gives the task in
question a fair chance is good enough.

> Does that make any sense?
> 
> This would mean that physical memory server and memory policy server
> trust task server. From the other side task server has to trust
> physical memory server. I'm not sure, but I'm afraid that it can be a
> desing problem.

Not at all.  The basic servers all trust each others.  After all,
physmem runs on threads provided and controlled by task, and task runs
on memory provided by physmem.

Marcus