l4-hurd
[Top][All Lists]
Advanced

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

Re: Another question about self-paging


From: Bas Wijnen
Subject: Re: Another question about self-paging
Date: Sun, 30 Oct 2005 19:31:29 +0100
User-agent: Mutt/1.5.11

On Sun, Oct 30, 2005 at 07:08:44PM +0100, ness wrote:
> Imagine dynamic linking of libraries. To save space the text segment of 
> the library exists only once in memory and is mapped read-only into the 
> application's AS (while checking this now I remember that the complete 
> exists only once in memory). So if on memory pressure an application has 
> to select a page to evict and selects a page of the ro-mapped 
> text-segment,

Not exactly.  The current idea (although there seem to be problems with it) is
to give processes some guaranteed pages and some extra pages.  The exact
amounts of them are negotiated at program startup and at certain intervals
(this is where the problems are, but I shall not talk about them now).

Memory pressure would mean "the process gets less guaranteed pages during
renegotiation of the amounts".  Most probably, the extra pages are already
unmapped.  At this moment, the process will need to page out some of its
guaranteed pages.

So for this scenario to work, the library must be in the guaranteed pages of
the process.  This is not the case though, it is in the (guaranteed or extra)
pages of the file system, which provides a mapping to them in a container to
all the processes which use it.  They can unmap it if they feel the pressure
(when they use more than 4GB memory), but that doesn't usually happen.

So in short: When a process is asked to reduce its guaranteed pages, it must
page out data that it owns.  The shared library is mapped into its address
space, but not owned by the process.  So unmapping it doesn't help.

> two things happen:
> 
> 1. To really make the eviction useful the page has to be unmapped from
>    every application that has mapped it (and paged out). This breaks the
>    self-paging idea, IMHO, as the applications didn't even have a chance
>    to influence this.
> 
> 2. The next application accessing the lib will significantly slow down
>    (fetch page from swap, map it into the app's AS) and all other apps
>    will slow down a bit (remap page into AS).

As you point out, this gives security problems (and usability problems as
well).  Fortunately, the process is not allowed to perform this operation. :-)

> This could be solved in a way like described in [1], but maybye there's 
> only sth. wrong with my understanding of self-paging.

I think so. :-)  But there are problems with the renegotiation which may not
be solvable in a satisfying way, which would mean we need some other approach.

Thanks,
Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://129.125.47.90/e-mail.html

Attachment: signature.asc
Description: Digital signature


reply via email to

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