diff options
author | David Howells <dhowells@redhat.com> | 2009-11-19 18:10:57 +0000 |
---|---|---|
committer | David Howells <dhowells@redhat.com> | 2009-11-19 18:10:57 +0000 |
commit | 3bde31a4ac225cb5805be02eff6eaaf7e0766ccd (patch) | |
tree | 9fb757ab7d46e0c37fb5e88d3185f1861fbc794e /fs/fscache | |
parent | 31ba99d304494cb28fa8671ccc769c5543e1165d (diff) | |
download | linux-3bde31a4ac225cb5805be02eff6eaaf7e0766ccd.tar.bz2 |
SLOW_WORK: Allow a requeueable work item to sleep till the thread is needed
Add a function to allow a requeueable work item to sleep till the thread
processing it is needed by the slow-work facility to perform other work.
Sometimes a work item can't progress immediately, but must wait for the
completion of another work item that's currently being processed by another
slow-work thread.
In some circumstances, the waiting item could instead - theoretically - put
itself back on the queue and yield its thread back to the slow-work facility,
thus waiting till it gets processing time again before attempting to progress.
This would allow other work items processing time on that thread.
However, this only works if there is something on the queue for it to queue
behind - otherwise it will just get a thread again immediately, and will end
up cycling between the queue and the thread, eating up valuable CPU time.
So, slow_work_sleep_till_thread_needed() is provided such that an item can put
itself on a wait queue that will wake it up when the event it is actually
interested in occurs, then call this function in lieu of calling schedule().
This function will then sleep until either the item's event occurs or another
work item appears on the queue. If another work item is queued, but the
item's event hasn't occurred, then the work item should requeue itself and
yield the thread back to the slow-work facility by returning.
This can be used by CacheFiles for an object that is being created on one
thread to wait for an object being deleted on another thread where there is
nothing on the queue for the creation to go and wait behind. As soon as an
item appears on the queue that could be given thread time instead, CacheFiles
can stick the creating object back on the queue and return to the slow-work
facility - assuming the object deletion didn't also complete.
Signed-off-by: David Howells <dhowells@redhat.com>
Diffstat (limited to 'fs/fscache')
0 files changed, 0 insertions, 0 deletions