[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.
Thanks,
Neal