On Wed, 6 Aug 2008 16:48:13 -0500, Bill Holder <[EMAIL PROTECTED]> wrote :
>On Wed, 6 Aug 2008 09:17:24 +0200, Rob van der Heij <[EMAIL PROTECTED]> wrote: > >>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 the >question of detaching memory. Although that mapping is indeed the "default" >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 address >backing it. > >So I basically agree with Alan's two choices - either we'd have to rewrite >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 poin t 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 removal. >Quite a lot of work, and more than a few nasty complications, either way. > >- Bill Holder, z/VM Development, IBM Perhaps I'm missing something, but doesn't XSTORE already meet those criteria? If so, adding the new storage as XSTORE to the LPAR and later removing said XSTORE from the LPAR is a much simpler task. Brian Nielsen
