Tony; Thanks for the correction. You are right, of course. I was assuming that eithe the opsys or millicode would fix the old psw before loading it. That can't be: If it were the opsys, it would be in PoOps, and if it were millicode, it wouldn't apply to real storage mode.
So, the question remains: Why have CC=3 for MVCLE? - Cashe line conflict? (E.g. changed on another processor.) - Hardware detected machine fault? (E.g. error correction fix up.) - Something else? Any ideas? On Mon, Jan 9, 2012 at 2:11 PM, Tony Harminc <[email protected]> wrote: > On 9 January 2012 04:40, Hobart Spitz <[email protected]> wrote: > > Suppose you wanted to move a large amount of data, and there are many > page > > faults involved. If you divide the moves into logical sections, and do > > each of the section moves in turn with MVCLE, you could go on to the next > > when one is interrupted. Doing this in a round-robin fashion, you could > > have your page faults being serviced in parallel. This could cut your > move > > time by roughly the reciprocal of the number of sections. It's a bit out > > there for applications, but program products (like DB2, sort, etc.) might > > benefit from such a technique. > > > > This is just speculation, but given the orders of magnitude difference > > between CPU speed and I/O speed could this explain be the reason for the > > CC=3 condition? > > I don't think it works. You can't both have a CC=3 from the > instruction, *and* have it cause a page fault. Even if the > hardware/millicode chooses to give you a CC=3 when it can't resolve an > address, there is no way for you to know that that's the problem. You > could, I suppose, assume that that's what went wrong, and issue your > own (async) pagein, but it doesn't sound like a very predictable > business. > > Tony H. > -- OREXXMan
