When demand paging is used,we sometimes need to allow some of the pages to be locked in memory.
One such situation occurs when I/O is done to or from user (virtual) memory.
I/O is often implemented by a separate I/O processor.
For example, a controller for a USB storage device is generally given the number of bytes to transfer and a memory address for the buffer (Figure 9.29).
When the transfer is complete,the CPU is interrupted.

We must be sure the following sequence of events does not occur.
A process issues an I/O request and is put in a queue for that I/O device.
Meanwhile,the CPU is given to other processes.
These processes cause page faults;
and one of them,using a global replacement algorithm,replaces the page containing the memory
buffer for the waiting process.
The pages are paged out.
Some time later,when the I/O request advances to the head of the device queue,the I/O occurs to the
specified address.
However,this frame is now being used for a different page belonging to another process.
There are two common solutions to this problem.
One solution is never to execute I/O to user memory.
Instead,data are always copied between system memory and user memory.
I/O takes place only between system memory and I/O device.
To write a block on tape,we first copy the block to system memory and then write it to tape.
This extra copying may result in unacceptably high overhead.
Another solution is to allow pages to be locked into memory.
Here,a lock bit is associated with every time frame.
If the frame is locked,it cannot be selected for replacement.
Under this approach,to write a block on tape,we lock into memory the pages containing the block.
The system can then continue as usual.
Locked pages cannot be replaced.
When the I/O is complete, the pages are locked.
Lock bits are used in various situations.
Frequently,some or all of the operating-system kernel is locked into memory,as many operating systems cannot tolerate a page fault caused by the kernel.
Another use for a lock bit involves normal page replacement.
Consider the following sequence of events:
A low-priority process faults.
Selecting a replacement frame,the paging system reads the necessary page into memory.
Ready to continue,the low-priority process enters the ready queue and waits for the CPU.
Since it is the low-priority process,it may not be selected by the CPU scheduler for a time.
While the low-priority process waits,a high a high-priority process faults.
Looking for a placement ,the paging system sees a page that is in memory but has not been referenced or modified:It is the page that the low-priority process just brought in.
That page looks like a perfect replacement :
It is clean and will not need to be written out,and it apparently has not been used for a long time.
Whether the high-priority process should be able to replacement the low-priority process is a policy
decision.
After all,we are simply delaying the low-priority process for the benefit of the high-priority process.
However,we are wasting the effect spent to bring in the page for the low-priority process.
If we decide to prevent replacement of a newly brought-in page until it can be used at least once,then we can use the lock bit to implement this mechanism.
When, a page is selected for replacement its lock bit is turned on;
it remains on until the faulting process is again dispatched.
Using a lock bit can be dangerous.
The lock bit may get turned on but never turned off.
Should this situation occur(because of a bug in the operating system,for example),the locked frame becomes unusable.
On a single-user system,the overuse of locking would hurt only the user doing the locking.
Multiuser systems must be less trusting of users.
For instance,Solaris allows locking “hints”,but it is free to disregard these hints if the free-frame pool becomes too small or if an individual process requests that too many pages be locked in memory.