Disk IO without doing IO's

[Cass Witkowski]

Direct I/O does not always mean disk I/O. Direct I/O means that the data buffer is in the user's space and that the I/O device transfers data to or from that location.

In most if not all cases it means that DMA is being used in the transfer. The transfer takes less time that the user process could be swapped out right after the transfer has completed if necessary.

Buffered I/O means that the data in the user's space is first copied to a buffer in system's space. From this system buffer it is then transferred out to the device. Typically this was program I/O with one byte or word of data being transferred at a time. Old DZ11 serial ports come to mind. Ethernet devices use DMA now days so their transfers are typically direct I/O.

Cass

[Uwe Zessin]

It is the device driver writer who decides if the IO is counted against BIO or DIO.

[Wim Van den Wyngaert]

But look at 1 and 2 : there is disk IO and NO direct nor buffered IO.

Wim

[Cass Witkowski]

Is high water marking turned on? Is there a process called I think BAD BLOCK running? Is this a shadowed disk member?

[Richard White_5]

Good Morning Wim...

>> Yesterday between 18 and 19h there was activity by the process going to dsa4. ... And the process has nothing to do with that disk but still there are IO's registered on that process ... << Exactly which utility is showing the Disk_I/O's being charged or registered to this "forsaken" process; and yet there is virtually no DIO's or BIO's against this process? ($monitor, $show proc, DecPS, etc.)

As Uwe mentioned, it is the device-driver, in particular, the Quadword-Mask fields at the front of the FDT-Routines that help determine whether or not the QIO's are Buff_I/O's or Dir_I/O's... I do not know of any other type of I/O that is processed by the FDT..

Is it possible to capture some of the process-context, (Image/Process-Sections, Channel-Control-Blocks, User/Kernel-Stack, Call-Frames from SDA ?)

Thanx,
whynot3k

[Wim Van den Wyngaert]

All findings are coming from VPA.

First SDA snapshot at 18:00.

VPA "display top", "Top Volumes by", "Image name" says the problem started at 18:00 sharp. The disks the process IPCDAEMON attacked was dsa1 (label disk1, rate 100IO/s) and dsa3 (label disk3, rate a little lower than dsa1). Thruput of the image to disk peaked at 7.5 MB/sec.

The snapshot may be taken just before the problem started.

Wim

[Wim Van den Wyngaert]

Second snapshot at 18:05. Problem was still present.

Wim

[Wim Van den Wyngaert]

Richard,

I'm only a SDA instructions repeater. Could you give me the statements for obtaining the data you need ?

Wim
(btw your morning is our evening/night)

[Wim Van den Wyngaert]

I did a show proc/con.
Not a single field is changing except that the cur priority toggles sometimes from 9 to 8 and directly back to 9 exactly every 1 minute. The disk IO rate during my 5 minutes test indicated 15 IO's/sec.

Wim

[Uwe Zessin]

Hm, does 'SHOW PROCESS/CONTINUOUS' send any SKASTs to the target process to collect some data? It sounds like the target is receiving a priority boost from somewhere.

From Heisenberg with Love ;-)