summaryrefslogtreecommitdiff
path: root/fs/fscache
diff options
context:
space:
mode:
authorDavid Howells <dhowells@redhat.com>2009-11-19 18:10:57 +0000
committerDavid Howells <dhowells@redhat.com>2009-11-19 18:10:57 +0000
commit3bde31a4ac225cb5805be02eff6eaaf7e0766ccd (patch)
tree9fb757ab7d46e0c37fb5e88d3185f1861fbc794e /fs/fscache
parent31ba99d304494cb28fa8671ccc769c5543e1165d (diff)
downloadlinux-3.10-3bde31a4ac225cb5805be02eff6eaaf7e0766ccd.tar.gz
linux-3.10-3bde31a4ac225cb5805be02eff6eaaf7e0766ccd.tar.bz2
linux-3.10-3bde31a4ac225cb5805be02eff6eaaf7e0766ccd.zip
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