"Schuh, Richard" <[EMAIL PROTECTED]> writes:
> As others have pointed out, accessing an active SFS directory can be
> a big contributor. I confirmed this by letting a machine sit idle
> for 2 hours while it had such a directory accessed. After 2 hours, I
> released the directory and it was disconnected 15 minutes later. In
> this case, I would expect to see VTIME incrementing because CMS is
> accepting the interrupts. If they are IUCV interrupts, that measure
> is blown out the door, too. Is there no such thing as an idle user
> anymore?

cp kernel time charge to the virtual machine ... can be anything that
the kernel does on behalf of the process.

I had originally done the pageable kernel stuff on cp/67 (as an
undergraudate) ... by creating a dummy virtual machine id (called
system) with dummy virtual address space tables ... into which were
mapped all the kernel code.  the end of the fixed kernel was
identified and then everything else was was allowed to "page". this
wasn't shipped as part of cp/67 but was picked up as part of vm370.

when I did the swaptable migration ... i created an abbreviated psuedo
virtual address space for each virtual machine ... primarily so that
the paging subsystem could be leveraged for moving data to/from disk.
basically nearly all control blocks could be copied into this dummy
virtual address space ... leaving only a small stub left in real
storage. at least one of the vm370-based time-sharing service bureaus
got very aggresive with this technique in the amount of resources that
an idle virtual machine had left behind in real storage:
http://www.garlic.com/~lynn/subtopic.html#timeshare

when idle virtual machine was found, the kernel overhead for moving
various control blocks out of storage to disk would be charged against
that virtual machine. however, it wouldn't be ongoing ... unless the
virtual machine was being periodically woken up for other reasons (and
the control blocks had to be brought back and then again removed
later).

i shipped this as part of the vm370 resource manager. recent post
referencing resource manager announcement letter:
http://www.garlic.com/~lynn/2006.html#19 DCSS as SWAP disk for z/Linux

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

Reply via email to