Martin, please correct me if i am wrong.
Large page support supports 1mb pages - meaning consecutive 256 4k pages
in hardware. These pages are "fixed", are not pageable with current
technology. The advantage is that there is one TLB entry per megabyte
instead of one per 4k page, so that the TLB is more efficient and more
entries fit into the hardware cache, requiring less DAT translations.
To get advantage then, there would have to be 1mb of very active
programs or data packaged in that 1mb page. Operating systems could be
packaged for this with work. zTPF took advantage of this, but that
architecture is focused on performance, not virtualization.
For oracle, it would require dedicating 256 consecutive hardware pages
to an oracle database, running virtual under linux, running virtual
under z/vm - yep, quite a challenge. In a virtual environment where we
do run many different programs - the benefit to programs and data would
be difficult to show.
The benefits of large pages are to those places that can and do measure
differences in performance at the single digit percentage difference
(zTPF). z/VM could get a little advantage with a lot of work, linux in
an LPAR as well. Linux under z/VM not. I would be surprised if the
improvement was measurable in any truly virtualized environment.
Martin Schwidefsky wrote:
On Sat, 28 Nov 2009 12:07:16 +1000
Shane <ibm-m...@tpg.com.au> wrote:
I missed the earlier part of this thread, but is large page support even
in z/VM ?. Alan ?.
I have a recollection that Mario Held from the Boeblingen labs said this
has been tested, but only for an LPAR install. And I'm pretty sure I
followed up on this and got the answer it's not even in V6.1.
Happy to be proved wrong.
Large page support is not available in z/VM, in particular guest
support is pretty hard to do. But the nice thing is: you don't need
guest support to reap the main benefit of large pages. There are two
benefits:
1) Less TLB entries for the same amount of addressed shared memory.
2) Reduced memory overhead for the page tables to map the shared memory.
You get TLB saving only on LPAR with the hardware support but you can
get the page table savings on z/VM with a little trick. Allocate huge
pages like you do if you have the hardware support. Then in addition
allocate a page table page to map the huge page and associate it with
the huge page. When the huge page is mapped to a process use the same
page table for all mappers. Sort of a poor man page table sharing. This
trick works on z/VM and on older machines that do not even have large
pages.
On non-s390 one of the big plusses is avoiding TLB misses. But given
that I believe z/VM also doesn't support hiperdispatch, that may not be
much of a gain on zSeries either.
I don't see the connection between TLB misses and hiperdispatch. Could
you elaborate please?
--
blue skies,
Martin.
"Reality continues to ruin my life." - Calvin.
----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
