l4-hurd
[Top][All Lists]
Advanced

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

Re: Paging Interface


From: Niels Möller
Subject: Re: Paging Interface
Date: 16 Jun 2002 17:27:35 +0200
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

address@hidden (Neal H. Walfield) writes:

> My qualm is that I think that we can export the paging policy to user
> space which is not currently done, however, I do not know how this
> should be done.

I see. It might make sense to let each "page owner" (for instance a
server that's responsible for the block cache, or the default pager
that is responsible for usual data pages) be responsible for the
continuous work of syncing pages to disk.

Then the work that remains for a special physical memory server is to

1. Keep information on the amount of pages allocated for various
   purposes (block cache, r/w data, ro mmapped files, etc),

2. Keep track of least-recently-used information and the like.

3. Guide the continuous syncing processes, using the above
   information.

4. If the system gets low on memory, tell page-owners that they must
   return some pages to the system (hopefully, they have some pages
   that are synced and not modified, so that they can be returned
   immediately).

Ok, I'm not sure this makes any sense, I've never written any paging
code, and there's probably lots of work, e.g. uvm, put into this area.

> I think that UVM has a lot of important ideas that we can pull from.
> However, I do am not sure that it can play a larger role than the
> anonymous memory server and default pager.

What's the interface between uvm and the rest of the kernel?

> Kevin suggested that an economic model might be interesting.  A
> physical memory server would be started on system boot and then all
> tasks would be allocated so much money on start up.

Sounds like an interesting research topic. At startup, there's lot of
free physical memory which can be sold cheaply. When memory gets more
scarce, price rises, and a page owner can compare the offered price to
its cost associated with selling a page, which is the work needed to
sync the page to disk (or zero, if it's already synced) and the costs for
paging it back in (including both buying a new page, and i/o work) at
a later time, where "later time" means one needs to estimate the time
it will take until the page is needed again, and multiply by a
suitable power of the interest.

Regards,
/Niels



reply via email to

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