xfs
[Top] [All Lists]

Re: [PATCH 5/6] xfs: convert the xfsaild threads to a workqueue

To: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Subject: Re: [PATCH 5/6] xfs: convert the xfsaild threads to a workqueue
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Sun, 3 Apr 2011 10:38:47 +1000
Cc: xfs@xxxxxxxxxxx
In-reply-to: <20110319134500.GB10056@xxxxxxxxxxxxx>
References: <1299715529-11026-1-git-send-email-david@xxxxxxxxxxxxx> <1299715529-11026-6-git-send-email-david@xxxxxxxxxxxxx> <20110310174818.GE19609@xxxxxxxxxxxxx> <20110318040648.GG30195@dastard> <20110319134500.GB10056@xxxxxxxxxxxxx>
User-agent: Mutt/1.5.20 (2009-06-14)
On Sat, Mar 19, 2011 at 09:45:00AM -0400, Christoph Hellwig wrote:
> On Fri, Mar 18, 2011 at 03:06:48PM +1100, Dave Chinner wrote:
> > It gets used by a second caller in the next patch that uses a
> > timeout of zero. The idea of adding a delay to a normal push is to
> > rate limit the number of times we do work so we always work on
> > batches rather a few items at a time in multiple executions of the
> > work.
> >
> > I'll see if it's simpler to just do this work directly in teh
> > callers, though.
> 
> I don't think hiding this delay (uncommented) in the workqueue use is
> a good idea.

FWIW, we already have an implicit delay for frequent callers when
the AIL is busy - the uninterruptible sleep for  sleeps of <= 20ms.
That was implemented specifically to rate-limit wakeups while the
xfsaild was busy pushing. This is essentially a different
implementation of the same mechanism.

> xlog_grant_push_ail has all the logics about when to push
> the AIL, so any batching should be grouped with that logic, and
> documented there.  It in fact already has some comments static that
> a min/max watermark scheme would be useful.

Yes, it does, but that's a much bigger change that has some
potentially nasty problems like ensuring the watermarks are always a
sane distance apart which is difficult to do on small logs were a
single transaction reservation can easily be larger than 10% of the
log. Hence watermarks are a much harder change to validate and tune
compared to a simple push wakeup rate-limit...

Cheers,

Dave.
-- 
Dave Chinner
david@xxxxxxxxxxxxx

<Prev in Thread] Current Thread [Next in Thread>