Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!pacbell.com!decwrl!ucbvax!ucf1vm.BITNET!news
From: news@ucf1vm.BITNET
Newsgroups: comp.lang.asm370
Subject: Re: New System/3x0 Instruction
Message-ID: <9103211718.AA01423@ucbvax.Berkeley.EDU>
Date: 21 Mar 91 16:43:17 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Reply-To: IBM 370 Assembly Programming Discussion List
              <ASM370@OHSTVMA.BITNET>
Distribution: inet
Organization: The Internet
Lines: 46

(You know, this is all getting a liitle out of hand)

The original Posting I wrote was for comments on a proposed 370 instruction,
MVDL, or move and discard character long.
The "discard" had to to with the data, not the area;
there is no implicit FREEMAIN (this is an instruction, NOT an OS service).

The instruction was meant to be coded as a direct replacement for MVCL,
in those situations where the source area need not be assumed
to hold valid data, after it was moved to the target area.

Inititial implementation would simply treat MVDL
as an MVCL.  The situation of improvement would be that, to minimize
page swapping and contention (which can occur and really wipe out performance
when you are dealing with 20MB blocks in 200MB regions),
the instruction could be extended to tie into the page tables;
if the new area and the old area both be on page boundaries,
and the length to be moved be integral pages,
then instead of ||:swap-in-the-old/swap-in-the-new/copy/repeat:||,
the page table could be marked up to have the user's target area page
references now point to the original (physical) source area.
Thus no physical swapping or copying of data would be required;
although page table manipulation is (perhaps) expensive, swapping contention
can be disastrously slow and ridiculously expen$ive.

(Perhaps "4-page" or "8-page" boundaries and lengths make more sense,
given the way auxiliary storage works.  Fine.  Then treat MVDL as MVCL
unless THOSE condition is met.  The point is, the application code
remains unchanged, and the operating system figures out the most
efficient way to handle a specific invocation of the instruction.)

This idea was discussed (at SHARE) with a fair number of IBMers,
with MVS, VM, and AIX experience.  All agreed that such a feature
would be useful, and could potentially lead to orders-of-magnitude
improvement in performance of a fair number of existing applications.
Noone suggested the MovePage; it is still not clear to me that it
would accomplish the desired result
(MovePage would also require a lot of recoding).  All agreed that such a
feature would be useful.

I do appreciate the comments made, and anticpate more.

Thanks,
        Dave

Dave Weintraub (dave@visual1.jhuapl.edu or dave@aplvm.bitnet)