From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Howells Subject: Re: [PATCH 01/45] Create a dynamically sized pool of threads for doing very slow work items [ver #41] Date: Fri, 19 Dec 2008 12:12:34 +0000 Message-ID: <10752.1229688754@redhat.com> References: <10438.1229686960@redhat.com> <20081219041401.GA29316@us.ibm.com> <20081120144139.10667.75519.stgit@warthog.procyon.org.uk> <20081120144145.10667.39594.stgit@warthog.procyon.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: nfsv4@linux-nfs.org, linux-kernel@vger.kernel.org, dhowells@redhat.com, viro@ZenIV.linux.org.uk, linux-fsdevel@vger.kernel.org, "Serge E. Hallyn" Return-path: In-Reply-To: <10438.1229686960@redhat.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: nfsv4-bounces@linux-nfs.org Errors-To: nfsv4-bounces@linux-nfs.org List-Id: linux-fsdevel.vger.kernel.org David Howells wrote: > I guess I need to stick a comment in slow_work_enqueue() to detail this, > though the comments in slow_work_execute() do talk about it. How about this: diff --git a/kernel/slow-work.c b/kernel/slow-work.c index f638f36..adf9b78 100644 --- a/kernel/slow-work.c +++ b/kernel/slow-work.c @@ -195,12 +195,32 @@ int slow_work_enqueue(struct slow_work *work) BUG_ON(!work->ops); BUG_ON(!work->ops->get_ref); + /* when honouring an enqueue request, we only promise that we will run + * the work function in the future; we do not promise to run it once + * per enqueue request + * + * we use the PENDING bit to merge together repeat requests without + * having to disable IRQs and take the spinlock, whilst still + * maintaining our promise + */ if (!test_and_set_bit_lock(SLOW_WORK_PENDING, &work->flags)) { spin_lock_irqsave(&slow_work_queue_lock, flags); + /* we promise that we will not attempt to execute the work + * function in more than one thread simultaneously + * + * this, however, leaves us with a problem if we're asked to + * enqueue the work whilst someone is executing the work + * function as simply queueing the work immediately means that + * another thread may try executing it whilst it is already + * under execution + * + * to deal with this, we set the ENQ_DEFERRED bit instead of + * enqueueing, and the thread currently executing the work + * function will enqueue the work item when the work function + * returns and it has cleared the EXECUTING bit + */ if (test_bit(SLOW_WORK_EXECUTING, &work->flags)) { - /* can't queue lest we cause multiple threads to try - * executing this item, so defer for later */ set_bit(SLOW_WORK_ENQ_DEFERRED, &work->flags); } else { if (work->ops->get_ref(work) < 0) David