Re: self-paging

[Jonathan S. Shapiro]

On Fri, 2005-12-02 at 15:52 +0100, Bas Wijnen wrote:
> > The point: you don't need to notify the application of anything in order
> > to let the application define residency requirements.
> 
> Well, it's all fine when the quota decreases.  A page will be swapped out, and
> the process will get a page fault at some point.  In response to that it can
> reoptimise its strategy (how much cache to have, for example).
> 
> However, this doesn't work when the quota increases.  Assume a process which
> wants as much cache as possible, but only in physical memory.  When it knows
> how much it can use, it will allocate that and use it.  As long as it isn't
> notified, it doesn't start using more, even if that would be more efficient.
> Of course it could poll for its quota every now and then, but that doesn't
> seem right.  It just adds work to the process while all the information to
> notify it is available.

I think I made my statement badly. What I meant to say was: you don't
need to notify the application in order to let the application specify
how pages compete for residency.

That is: expressing preference about what to page out doesn't require
notification. You don't need notification until your application wants
to do adaptive overall residency.

> We always need to consider channels, except with hard page frame commitments.
> 
> >   2. Soft reservations are adjusted only in response to user action.
> >      For example, when your window ceases to be in front, we can tell
> >      you safely that your CPU contract and memory contract are reduced.
> 
> While this would not be an acceptable policy for me, I agree that the idea can
> work.  I'm not sure if I'd like it though.  I think I prefer to have settings
> for the quota which can be bound by the user (so dynamic values, but limited
> to a range).

Two examples to consider:

1. Video. Front window closes, resources get rotated so that the new
front video window now gets "frontmost" resources.

2. Tuning knobs: app gives jaggy video, user turns a quality knob.

I'm curious what application you have in mind where you feel that the
resource should be dynamically adaptive without user intervention. I can
think of some, but for most of them I end up concluding that dynamic
adaptivity isn't well motivated.

So: what application are you thinking about?

> >       [User-driven changes] does not create a channel issue,
> 
> It does.  The channel is just very low bandwidth...

Actually, it does not. The user's authority to change those resource
commitments is explicit. It's an *overt* channel. What I was trying to
say above is that there is no *covert* channel issue.

>   But if a process runs for
> days, and some program is so slow at certain actions that the user will go do
> something else while it's working, then that is noticable by other processes
> and it can be used as a communication channel.

Clever observation. I had failed to consider exploiting the multiplexing
behavior of the user. Clearly we need to assign well-defined schedules
to the users, and constrain them to act according to those
schedules. ;-)

> >       and it seems to deal very well with the problems that people are
> >       really trying to solve when they do this type of adaptive reservation.
> 
> The policy you gave (foreground == highest priority) is very single-tasking
> oriented.  I like to do things in the background, and I wouldn't like it if
> those things get less resources just because I'm typing in an other window.  I
> think this is not just a nerd-thing.

Actually, I wasn't thinking in single-tasking terms. What I was thinking
was based on a very basic observations: the human doesn't really care
how fast the updates are on bits that are not visible. Further, if you
have three movies stacked in overlapping windows, I'm pretty confident
that you aren't watching the back movie at full fidelity.

So yes, there is some need for multitasking here, and it may be
necessary not to penalize the second movie player too much. But
ultimately, it's the *user* who has limited tasking capabilities, and if
the goal is to support interactive applications it's reasonable to
exploit that fact.

> What your reply didn't comment on is the two big parts of my proposal:
> 
> - The application manages a list of its pages, thereby it can do its own
>   paging (literally while the quota don't change, only preparing the order
>   when they do).  What I didn't mention yet, is that I fear this may cause
>   overhead (because the list must be managed with system calls to physmem).
>   Perhaps this isn't a problem if the management is simply ignored until
>   swapping starts.  What that happens, RPC performance is no longer a
>   significant factor anyway.

What you are trying to achieve is fine, but I think that this particular
mechanism will be cumbersome. I think the application should instead
define working set contexts for regions in its virtual address space,
and then define a replacement policy for each context. The association
between a frame and its dominating context is maintained within the OS,
and is not explicitly disclosed to the application.

> - Change the quota very slowly, not immediately on every event, so the
>   communication channel is narrowed.

Better still, change it at known intervals that are long enough to
obscure individual behavior. For example, recompute every K seconds.


shap