RE: FPage

Hmm, Good question. Maybe I'm wrong here.

> As far as I remember, there was a good reason for this limitation: a part=
ial
> unmap of a small fraction from a large fpage might consume a lot of time =
and
> memory. It's just a behaviour you didn't want to encourage.

Implementation-wise, you're definitely right. But I didn't know that partic=
ular paragraph in the manual, just thought that there is no conceptual reas=
on to disallow partial mappings (the MDB is infinitely complicated anyway).=
=20

-Jan


--
Dr.-Ing. Jan Stoess
KIT/UKa System Architecture Group
Phone: +49 (721) 6084 4056
Fax: +49 (721) 6084 7664
http://os.ibds.kit.edu/stoess=20


> -----Original Message-----
> From: Mart=EDn Knoblauch Revuelta [mailto:[email protected]]
> Sent: Wednesday, January 19, 2011 15:47
> To: Jan Stoess
> Subject: Re: FPage
>=20
> Hi Jan,
>=20
> Wolf Ramovsky wrote:
> >> [..]
> >> For example I requested to map 8 KiB at 0x0000_0000 and then trying
> >> to unmap 4 KiB starting from 0x0000_0fff. Is it possible or not? Is it=
 possible,
> e.g.
> >> to unmap a part from previously mapped fpage, or I should unmap only
> >> full fpage mapped previously, with the same address and size it was
> mapped?
>=20
> Jan Stoess wrote:
> > No, you can also unmap parts. The hardware page size is the limit.
>=20
> Are you sure? It didn't use to be that way. Have you changed it? Indeed, =
the
> manual still says:
>=20
>    << Mapped fpages are considered inseparable objects. That is, if an fp=
age is
> mapped, the mapper can not later partially unmap the mapped page; the
> whole fpage must be unmapped in a single operation. The mappee can,
> however, separate the fpage and map fpages (objects) of smaller size. Par=
tially
> unmapping an fpage might or might not work on some systems. The kernel wi=
ll
> give no indication as to whether such an operation succeeded or not. >>
>=20
> As far as I remember, there was a good reason for this limitation: a part=
ial
> unmap of a small fraction from a large fpage might consume a lot of time =
and
> memory. It's just a behaviour you didn't want to encourage.
>=20
> Best regards,
> Martin