On Thu, 12 Jan 2012 10:13:03 -0500 Hobart Spitz <[email protected]> wrote:
:>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? Ability to allow higher priority work to run without interrupting the milicode and without the need to save the status in the milicode. :>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. -- Binyamin Dissen <[email protected]> http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies.
