Hoorcollege 7:
Input / Output requires the communication between software and resources. If you have a piece of
software it requires some interaction with the surroundings and it needs to do this by acquiring
resources. Resources are then allocated, and they return a communication channel (e.g. where is the
mouse pointer on the desktop or acquiring a communication channel over the network). There are a
few communication modes, you can have a resource channel that:
- Read, write, read + write
- Uni(you sent information in one direction where is a receiver), bi(question-answer, question-
answer), multi(Targeted to multiple communication partners), omni-directional(Broadcast
that is sending information to everyone who wants to listen to it)
Resources are not only files it can for example be: memory data segments, USB/Cable connection
and network channels.
Doing I/O has a performance cost. The performance cost can be split into:
- Control cost: synchronisation between two partners in the input/output, CPU is waiting for
the bus to not be busy anymore(bus-busy) & waits, bus checks
- Data cost: Cache & memory misses, sending the information and how long the actual
transmission time is.
Direct read/write: read/write each byte as it is available, you read or write every single byte for
example if you have a file and you want to read it, you can do this with every single byte piece by
piece. This is very responsive if you want to read it, but you have a high control cost.
Buffering: gather several multi-bytes in buffer area so you can transmit a whole buffer content in 1
go, lesser control cost because you sent them in bulk. Generally buffering is good, as transmission
delays are offset by bus use increase. This is an exception for CPU <-> RAM <-> GPU. We don’t buffer
with these components because they are very speedy.
There is difference between how you aces input/output channels you can do this in a:
- Blocking way I/O: Synchronous data transfer:
o Resources accessed with read() or write() the second request will
be blocked
o Resources is released when operation finished
o During that time: CPU cannot do anything else; other accessing
processed are in blocked state
o Inefficient usage of CPU computing time
- Non-blocking I/): asynchronous data transfer:
o Process want to access resource:
▪ 1. Check if resource is free/available -> check()/wait()
▪ 2. If resource is available: access & block resource
▪ 3. If resource not available: the process can do something else check again
later or register a call-back
o Once released, the resource can be allocated by other processes again.
o Non-blocking I/O: implemented by Driver or by application itself
o Advantage: better CPU usage because there are no blocked processes,
Disadvantage: CPU & Bus overhead from check()(control checks) calls.
, (non-)blocking I/O; access check occur frequently & take lots of time, we can achieve efficient checks
by:
- Polling: periodically request access status -> lots of overhead(left figure). When you have a
function, you want to acquire data from resource, it doesn’t work like that, you return and
pull all the time.
- Interrupts & call-backs: ask for access; register a function that is executed when resource is
available(right figure). If you want to read from a certain device, than you initiate the driver
and you tell the driver to register a certain call back function (in table after arrow 4) and you
return the control back to your normal execution pipeline. When the data is available than
the interrupt handler will call the device that the data is available and this function which
was registered in the table is executed and tells the process that there is new data available.
This relieves (verlicht) the processor from all the polling checks if an Input/output channel is
available.
Address space to a certain I/O device into the main memory or the virtual address space. This can we
do with direct memory mapping. We map the memory space of our input/output device into the
main memory so now we can do direct communication to the address space with our I/O. Result:
lots of unnecessary memory-copy operations. We can avoid unnecessary buffer copies by:
- Memory mapping:
o Requires tightly-coupled I/O partners (i.e. internal data).
They need to be connected somehow and also required
update cycles. If we have a process that wants to write into
the I/O than all the changes that are done in main memory
need to be communicated back to the Input/Output device.
The advantage is that the OS can control when this I/O
happens based on for example that the bus is not busy.
o Maps the memory of one partner directly in the memory
space of the other -> shared memory
o Accessing one another’s memory is equal to accessing own
memory
- Added performance costs: Update cycles.
Input / Output requires the communication between software and resources. If you have a piece of
software it requires some interaction with the surroundings and it needs to do this by acquiring
resources. Resources are then allocated, and they return a communication channel (e.g. where is the
mouse pointer on the desktop or acquiring a communication channel over the network). There are a
few communication modes, you can have a resource channel that:
- Read, write, read + write
- Uni(you sent information in one direction where is a receiver), bi(question-answer, question-
answer), multi(Targeted to multiple communication partners), omni-directional(Broadcast
that is sending information to everyone who wants to listen to it)
Resources are not only files it can for example be: memory data segments, USB/Cable connection
and network channels.
Doing I/O has a performance cost. The performance cost can be split into:
- Control cost: synchronisation between two partners in the input/output, CPU is waiting for
the bus to not be busy anymore(bus-busy) & waits, bus checks
- Data cost: Cache & memory misses, sending the information and how long the actual
transmission time is.
Direct read/write: read/write each byte as it is available, you read or write every single byte for
example if you have a file and you want to read it, you can do this with every single byte piece by
piece. This is very responsive if you want to read it, but you have a high control cost.
Buffering: gather several multi-bytes in buffer area so you can transmit a whole buffer content in 1
go, lesser control cost because you sent them in bulk. Generally buffering is good, as transmission
delays are offset by bus use increase. This is an exception for CPU <-> RAM <-> GPU. We don’t buffer
with these components because they are very speedy.
There is difference between how you aces input/output channels you can do this in a:
- Blocking way I/O: Synchronous data transfer:
o Resources accessed with read() or write() the second request will
be blocked
o Resources is released when operation finished
o During that time: CPU cannot do anything else; other accessing
processed are in blocked state
o Inefficient usage of CPU computing time
- Non-blocking I/): asynchronous data transfer:
o Process want to access resource:
▪ 1. Check if resource is free/available -> check()/wait()
▪ 2. If resource is available: access & block resource
▪ 3. If resource not available: the process can do something else check again
later or register a call-back
o Once released, the resource can be allocated by other processes again.
o Non-blocking I/O: implemented by Driver or by application itself
o Advantage: better CPU usage because there are no blocked processes,
Disadvantage: CPU & Bus overhead from check()(control checks) calls.
, (non-)blocking I/O; access check occur frequently & take lots of time, we can achieve efficient checks
by:
- Polling: periodically request access status -> lots of overhead(left figure). When you have a
function, you want to acquire data from resource, it doesn’t work like that, you return and
pull all the time.
- Interrupts & call-backs: ask for access; register a function that is executed when resource is
available(right figure). If you want to read from a certain device, than you initiate the driver
and you tell the driver to register a certain call back function (in table after arrow 4) and you
return the control back to your normal execution pipeline. When the data is available than
the interrupt handler will call the device that the data is available and this function which
was registered in the table is executed and tells the process that there is new data available.
This relieves (verlicht) the processor from all the polling checks if an Input/output channel is
available.
Address space to a certain I/O device into the main memory or the virtual address space. This can we
do with direct memory mapping. We map the memory space of our input/output device into the
main memory so now we can do direct communication to the address space with our I/O. Result:
lots of unnecessary memory-copy operations. We can avoid unnecessary buffer copies by:
- Memory mapping:
o Requires tightly-coupled I/O partners (i.e. internal data).
They need to be connected somehow and also required
update cycles. If we have a process that wants to write into
the I/O than all the changes that are done in main memory
need to be communicated back to the Input/Output device.
The advantage is that the OS can control when this I/O
happens based on for example that the bus is not busy.
o Maps the memory of one partner directly in the memory
space of the other -> shared memory
o Accessing one another’s memory is equal to accessing own
memory
- Added performance costs: Update cycles.
