[K42-discussion] Large page pinning on K42

[Orran Y Krieger]

We have only run large page experiments with HPC applications, and for 
those experiments we turned off the paging daemon... :-)  I have a bunch 
more code, sitting to be committed if i ever get back to it in the pagign 
space.  Not sure when that will be, sigh...  If you want to look at this 
space let me know and i can pass you what i was working on when I had to 
drop this. 



"YipKei Kwok" <yipkeikwok at gmail.com> 
02/22/2006 06:55 PM

To
Orran Y Krieger/Watson/IBM at IBMUS
cc
"K42 discussion mailing list" <k42-discussion at ozlabs.org>
Subject
Re: [K42-discussion] Large page pinning on K42






Hi Orran,

Although there is no explicit pinning on large pages in the previous
experiments as you mentioned, no large page has been paged out so far.
May I ask if there is any reason behind why this never occurs even
though paging for large pages is not disabled?

Thank you very much!

Regards,
Yipkei

On 2/17/06, Orran Y Krieger <okrieg at us.ibm.com> wrote:
>
> Yipkei,
>
> Hmmm, to be frank, I am not sure what would happen if you tried to page 
large pages.  I don't think I explicitly put in anything to disable paging 
for the large pages, but it certainly has never been exercised.  We have 
tended to use large pages for very specialized experiments, and paging 
would never have been kicked off in those experiments.  By the way, in 
defines/paging.H the default option is to emulate how Linux & AIX do 
things, with a fixed pool of large pages allocated up-front.  If you turn 
off that option, large pages are not restricted.  If you want to play in 
this space, it would be great.  I think it would make sense to do it in 
the context of the new chunk allocation that Chris has been putting in. 
The chunk based work is designed to keep memory unfragmented to better 
support large pages.  Basically, memory is handed to a process (or group 
of files) in a large chunk, and then sub-allocated.  That way, when, for 
example, a process goes away, a contigous memory is freed.
>
> There is no restriction on paging out of large pages, but on the 970 the 
only large page size is 16Meg.  Hence, its pretty darn expensive to page 
it.
>              -- Orran
>
>
>
>
>
>  YipKei Kwok <yipkeikwok at gmail.com>
> Sent by: k42-discussion-bounces+okrieg=us.ibm.com at ozlabs.org
>
> 02/17/2006 01:17 PM
>
> To K42 discussion mailing list <k42-discussion at ozlabs.org>
>
> cc
>
>
> Subject [K42-discussion] Large page pinning on K42
>
>
>
>
>
>
>
>
> Hi,
>
>  I have several questions regarding paging for large pages on the K42
>  operating systems.
>
>  1. By default, once a large page is allocated, is it pinned in the
>  memory so it will not be paged out? If no, is there any mechanism
>  which could enforce such a restriction?
>
>  2. Previous research has been done on K42 running on the PowerPC 970FX
>  (G5) processor. Was paging out of large pages restricted? If yes, is
>  the restriction imposed by the operating system or the processor?
>
>  Thank you very much!
>
>  Regards,
>  Yipkei
>
>  --
>  --
>  Web site:
>  http://360.yahoo.com/yipkeikwok
>  http://www.mcs.csueastbay.edu/~ykwok/
>  email addresses:
>  yipkeikwok at gmail dot com
>  ykwok2 at utep dot edu
>  ICQ UIN:    2309842
>  Google Talk ID:    yipkeikwok at gmail dot com
>  Yahoo! Messenger ID:    yipkeikwok
>  MSN Messenger ID:    yipkeikwok at hotmail dot com
>  _______________________________________________
>  K42-discussion mailing list
>  K42-discussion at ozlabs.org
>  https://ozlabs.org/mailman/listinfo/k42-discussion
>
>



--
--
Web site:
http://360.yahoo.com/yipkeikwok
http://www.mcs.csueastbay.edu/~ykwok/
email addresses:
yipkeikwok at gmail dot com
ykwok2 at utep dot edu
ICQ UIN:    2309842
Google Talk ID:    yipkeikwok at gmail dot com
Yahoo! Messenger ID:    yipkeikwok
MSN Messenger ID:    yipkeikwok at hotmail dot com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ozlabs.org/pipermail/k42-discussion/attachments/20060224/e93922c6/attachment.htm