l4-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: making paging decisions


From: Neal H. Walfield
Subject: Re: making paging decisions
Date: Tue, 26 Oct 2004 09:23:50 +0100
User-agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.6 (Maruoka) FLIM/1.14.6 (Marutamachi) APEL/10.6 Emacs/21.2 (i386-debian-linux-gnu) MULE/5.0 (SAKAKI)

> The main issue he expressed his
> concerns about is which strategy physmem should chose to ask back for
> frames.

When you say that physmem has a strategy to "ask [clients] back for
frames" do you mean renegotiating the contract for a guaranteed
allocation of physical frames?  If not, the only frames whic physmem
ever asks to return are extra frames.

> Of course, our basic model is that we leave these decisions to the
> tasks themselves, which only have a local view.  In fact, we can not
> even trust any information provided by an untrusted user.  A user
> would be likely to just lie about the priority and involved costs, to
> inflate the price and avoid being asked back for memory.

This is rather difficult: physmem doesn't know anything about
individual frames.  It knows that a task has an allowance of X
guaranteed frames and currently holds Y frames but it does not know
anything about the frames themselves.  This is all stored on the
client.  Where would you associate this data?  What is it useful for?
If the client reuses a frame (which will often happen) does it make an
RPC to physmem tell it or do we use a shared memory solution?

> But, there are things we can do.  First, it would be interesting to
> allow users to use one memory manager (or meta-manager) to manage the
> memory for all its tasks.  This would at least allow to take into
> account differences between a user's task.  That wouldn't be quite
> good enough, though.  I don't know enough to judge if it would be a
> real advantage at all.

This sounds like a fundamental paradigm shift.  What would this memory
manager do?


> Second, we can let tasks voluntarily de-value their memory.  This
> would work like nice(), and be completely voluntary.  Not many would
> use it.

Physmem should have an mechanism that if you use less guaranteed
frames then you are allowed when you need more you should have a
better chance of increasing your allocation.

> Third, tasks could announce their priorities and costs to physmem.
> Now, there must be a way to avoid inflation.  That way is to give
> tasks a benefit in return for not announcing high priorities and high
> costs.

This is my confusion: a guaranteed frame is a guaranteed frame.  How
are you trying to qualify the guarantee?

> This is basically the market-model idea, where tasks compete
> in using the memory, and some price is attached to memory.  We only
> have vague ideas on how to actually use it.

I think the market-model is good at memory allocation time
(i.e. competition for guaranteed frames).  I don't see how it would
change the any paging strategy.

> But the idea is that
> tasks would have an incentive to be modest about their claims to
> physmem, so that the priority and cost information is actually useful
> to make decisions about claiming back memory pages.  Physmem could
> then use that info, and any internal information that is available, to
> make moderatley smart requests to reclaim memory.

Physmem only reclaims extra pages.  Are you going to all of this
trouble for extra pages?




reply via email to

[Prev in Thread] Current Thread [Next in Thread]