[Top][All Lists]

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

Re: Status Bits and Super Pages

From: Neal H. Walfield
Subject: Re: Status Bits and Super Pages
Date: Thu, 23 Aug 2007 14:02:10 +0200
User-agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.6 (Marutamachi) APEL/10.6 Emacs/21.4 (i386-pc-linux-gnu) MULE/5.0 (SAKAKI)

At Thu, 23 Aug 2007 13:54:56 +0200,
Marcus Brinkmann wrote:
> > If so, it seems that if I want status bits for the pages that the
> > resource manager maps to its clients, then I have to be careful to
> > only map pages of the same size as the ones the manager has.  I
> > imagine that I can request new mappings from sigma0 as appropriate,
> Or insert an intermediate task.

This occured to me as well but my intuition suggests that the costs
are strictly greater than only have small mappings: now you have the
superpage mappings plus the small mappings and the overhead of
additional tasks.

> > but this basically defeats the advantage of having mapped the
> > superpages to begin with--most mappings will be small and thus the
> > address space with quickly be filled with small mappings.  Plus, with
> > this approach, there is the overhead of the cost of the unmap and
> > re-map operations.
> Yes.  However, there is a related problem that you can not unmap
> selectively.  I vaguely remember that Espen had a selective unmap
> proposal at some time as a small modification to the L4 X.2 interface.
> But I don't remember any details.  Whatever that proposal was should
> also provide an opportunity to do selective status bit checking,
> shouldn't it?

I think the problem was that the space had to be identified, however,
as the original recipient can grant the mapping meaning that the
mapping now exists in a different space, many complications ensue.


reply via email to

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