Anne & Lynn Wheeler
2006-01-27 02:18:26 UTC
***@ibm-main.lst wrote:
> I wonder about teD's statement that there remains a performance
> edge for VIO. I understand the paths for paging are highly
> optimized. But with modern buffered and virtual DASD the
> difference ought to be shrinking. And there's the offsetting
> overhead of emulating CKD protocol in virtual memory.
the original prototype for the move from MVT to VS2 ... involved
crafting cp/67's CCWTRANS into the side of MVT (excp processing). the
problem is simulating real i/o operations in a virtual memory environment.
basically excp/svc pointed to channel program. CCWTRANS was called to
scan the passed CCWs, creating a shadow channel program that was
actually going to be executed. each CCW from the original channel
program was copied into the shadow channel program, any referenced
virtual addresses had the associated virtual page fetched (if necessary)
and fixed in real memory, the real address of the virtual page was then
stuffed into the shadow ccw. when CCWTRANS was complete, the shadow
channel program (rather than the passed excp channel program) was
scheduled for executing (the virtual pages were pinned at real storage
so they wouldn't move until after the shadow channel program ... with
real addresses ... had finished)
at completion of the I/O operation, the shadow channel program was
rescanned ... and each virtual page that was pinned in the CCWTRANS pass
was then unpinned.
one of the savings in V=R is that the passed channel program can be
executed directly since all of the addresses are "real" and already pinned.
LPARs are essentially a subset of virtual machine ... with nearly
everything in hardware/microcode. LPAR support can get around the shadow
CCW stuff by slight hack to the hardware i/o support ... and having all
the memory for a LPAR contiguous. then the microcode just has to handle
base/bound relocation of every I/O address (i.e. rather than having to
translate every 4k virtual page to a real address, a fixed offset
address just needs to be added to every LPAR i/o address).
i had originally implemented page mapped filesystem for cms for cp/67
and then ported it to vm/370
http://www.garlic.com/~lynn/subtopic.html#mmap
there were all sorts of savings for the page mapped interface ...
eliminating the scan, shadowed ccws, page fixing, schedule real i/o,
rescan, and unfix, etc (even for cms disk i/o which already had a
fastpath version of CCWTRANs that i had originally done on cp/67 as an
undergraduate).
recent posting on some old comparisons of paged-mapped versus emulating
CCWs ... from a presentation that I had given at the fall '86 SEAS meeting
http://www.garlic.com/~lynn/2006.html#25 DCSS as SWAP for z/Linux
the topic in this particular thread is similar to VIO discussion
http://www.garlic.com/~lynn/2006.html#17 (SPAM?) DCSS as SWAP disk for
z/Linuz
http://www.garlic.com/~lynn/2006.html#18 DCSS as SWAP disk for z/Linux
http://www.garlic.com/~lynn/2006.html#19 DCSS as SWAP disk for z/Linux
http://www.garlic.com/~lynn/2006.html#25 DCSS as SWAP disk for z/Linux
random past postings referring to the original MVT->VS2 work using
CP/67's CCWTRANS
http://www.garlic.com/~lynn/2000c.html#34 What level of computer is
needed for a computer to Love?
http://www.garlic.com/~lynn/2001b.html#18 Linux IA-64 interrupts [was
Re: Itanium benchmarks ...]
http://www.garlic.com/~lynn/2001i.html#37 IBM OS Timeline?
http://www.garlic.com/~lynn/2001i.html#38 IBM OS Timeline?
http://www.garlic.com/~lynn/2001l.html#36 History
http://www.garlic.com/~lynn/2002l.html#65 The problem with installable
operating systems
http://www.garlic.com/~lynn/2002l.html#67 The problem with installable
operating systems
http://www.garlic.com/~lynn/2002p.html#49 Linux paging
http://www.garlic.com/~lynn/2002p.html#51 Linux paging
http://www.garlic.com/~lynn/2003k.html#27 Microkernels are not "all or
nothing". Re: Multics Concepts For
http://www.garlic.com/~lynn/2004e.html#40 Infiniband - practicalities
for small clusters
http://www.garlic.com/~lynn/2005b.html#49 The mid-seventies SHARE survey
http://www.garlic.com/~lynn/2005f.html#47 Moving assembler programs
above the line
http://www.garlic.com/~lynn/2005p.html#45 HASP/ASP JES/JES2/JES3
http://www.garlic.com/~lynn/2005s.html#25 MVCIN instruction
http://www.garlic.com/~lynn/2005t.html#7 2nd level install - duplicate
volsers
> I wonder about teD's statement that there remains a performance
> edge for VIO. I understand the paths for paging are highly
> optimized. But with modern buffered and virtual DASD the
> difference ought to be shrinking. And there's the offsetting
> overhead of emulating CKD protocol in virtual memory.
the original prototype for the move from MVT to VS2 ... involved
crafting cp/67's CCWTRANS into the side of MVT (excp processing). the
problem is simulating real i/o operations in a virtual memory environment.
basically excp/svc pointed to channel program. CCWTRANS was called to
scan the passed CCWs, creating a shadow channel program that was
actually going to be executed. each CCW from the original channel
program was copied into the shadow channel program, any referenced
virtual addresses had the associated virtual page fetched (if necessary)
and fixed in real memory, the real address of the virtual page was then
stuffed into the shadow ccw. when CCWTRANS was complete, the shadow
channel program (rather than the passed excp channel program) was
scheduled for executing (the virtual pages were pinned at real storage
so they wouldn't move until after the shadow channel program ... with
real addresses ... had finished)
at completion of the I/O operation, the shadow channel program was
rescanned ... and each virtual page that was pinned in the CCWTRANS pass
was then unpinned.
one of the savings in V=R is that the passed channel program can be
executed directly since all of the addresses are "real" and already pinned.
LPARs are essentially a subset of virtual machine ... with nearly
everything in hardware/microcode. LPAR support can get around the shadow
CCW stuff by slight hack to the hardware i/o support ... and having all
the memory for a LPAR contiguous. then the microcode just has to handle
base/bound relocation of every I/O address (i.e. rather than having to
translate every 4k virtual page to a real address, a fixed offset
address just needs to be added to every LPAR i/o address).
i had originally implemented page mapped filesystem for cms for cp/67
and then ported it to vm/370
http://www.garlic.com/~lynn/subtopic.html#mmap
there were all sorts of savings for the page mapped interface ...
eliminating the scan, shadowed ccws, page fixing, schedule real i/o,
rescan, and unfix, etc (even for cms disk i/o which already had a
fastpath version of CCWTRANs that i had originally done on cp/67 as an
undergraduate).
recent posting on some old comparisons of paged-mapped versus emulating
CCWs ... from a presentation that I had given at the fall '86 SEAS meeting
http://www.garlic.com/~lynn/2006.html#25 DCSS as SWAP for z/Linux
the topic in this particular thread is similar to VIO discussion
http://www.garlic.com/~lynn/2006.html#17 (SPAM?) DCSS as SWAP disk for
z/Linuz
http://www.garlic.com/~lynn/2006.html#18 DCSS as SWAP disk for z/Linux
http://www.garlic.com/~lynn/2006.html#19 DCSS as SWAP disk for z/Linux
http://www.garlic.com/~lynn/2006.html#25 DCSS as SWAP disk for z/Linux
random past postings referring to the original MVT->VS2 work using
CP/67's CCWTRANS
http://www.garlic.com/~lynn/2000c.html#34 What level of computer is
needed for a computer to Love?
http://www.garlic.com/~lynn/2001b.html#18 Linux IA-64 interrupts [was
Re: Itanium benchmarks ...]
http://www.garlic.com/~lynn/2001i.html#37 IBM OS Timeline?
http://www.garlic.com/~lynn/2001i.html#38 IBM OS Timeline?
http://www.garlic.com/~lynn/2001l.html#36 History
http://www.garlic.com/~lynn/2002l.html#65 The problem with installable
operating systems
http://www.garlic.com/~lynn/2002l.html#67 The problem with installable
operating systems
http://www.garlic.com/~lynn/2002p.html#49 Linux paging
http://www.garlic.com/~lynn/2002p.html#51 Linux paging
http://www.garlic.com/~lynn/2003k.html#27 Microkernels are not "all or
nothing". Re: Multics Concepts For
http://www.garlic.com/~lynn/2004e.html#40 Infiniband - practicalities
for small clusters
http://www.garlic.com/~lynn/2005b.html#49 The mid-seventies SHARE survey
http://www.garlic.com/~lynn/2005f.html#47 Moving assembler programs
above the line
http://www.garlic.com/~lynn/2005p.html#45 HASP/ASP JES/JES2/JES3
http://www.garlic.com/~lynn/2005s.html#25 MVCIN instruction
http://www.garlic.com/~lynn/2005t.html#7 2nd level install - duplicate
volsers