On Wed, 6 Aug 2008 09:17:24 +0200, Rob van der Heij <[EMAIL PROTECTED]> w rote:
>On Wed, Aug 6, 2008 at 8:06 AM, Alan Ackerman ><[EMAIL PROTECTED]> wrote: > >> Deleting memory is a lot harder. > >Many delicate CP areas now also are in virtual memory as a result of >the 2G relief, even though not all may be paged. >It depends a lot on the granularity of the next level of mapping. When >90% of your in-use pages is virtual machine pages, you can probably >find 16 MB worth of individual pages to give up. But evacuating pages >at random in the hope to free an entire 16MB chunk is less attractive >(I think some time ago pages under the bar would be freed like that). > ... > >Rob >======================== ========================= ======================== Just to emphasize the point - the fact that most of CP's storage is now mapped into virtual(the System Execution Space) is really irrelevant to t he question of detaching memory. Although that mapping is indeed the "defau lt" CP storage usage and CP code has to go "out of its way" to touch real storage directly, all SXS mappings are defined to be static at least for the duration of the usage, and many (like the nucleus and prefix areas) are outright permanent. A CP thread having rights to a given SXS virtual address gives it implicit rights for the same duration to the real addres s backing it. So I basically agree with Alan's two choices - either we'd have to rewrit e virtually everything to tolerate pageable (or at least re-assignable) CP storage, or we'd have to rewrite all of storage allocation to know that there's an area that might have to be depopulated on demand at some point in the future, such that only truly pageable uses can be allocated out of it . The latter approach is certainly simpler, but also more restrictive, requiring pre-planning and definition of the area subject to later remova l. Quite a lot of work, and more than a few nasty complications, either way. - Bill Holder, z/VM Development, IBM
