xfs
[Top] [All Lists]

Re: [PATCH 4/4] xfs: convert xfsbufd to use a workqueue

To: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Subject: Re: [PATCH 4/4] xfs: convert xfsbufd to use a workqueue
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Wed, 21 Sep 2011 16:25:39 +1000
Cc: xfs@xxxxxxxxxxx
In-reply-to: <20110826082515.GD3551@xxxxxxxxxxxxx>
References: <1314341497-23910-1-git-send-email-david@xxxxxxxxxxxxx> <1314341497-23910-5-git-send-email-david@xxxxxxxxxxxxx> <20110826082515.GD3551@xxxxxxxxxxxxx>
User-agent: Mutt/1.5.21 (2010-09-15)
On Fri, Aug 26, 2011 at 04:25:15AM -0400, Christoph Hellwig wrote:
> > index 13188df..a3d1784 100644
> > --- a/fs/xfs/xfs_trans_ail.c
> > +++ b/fs/xfs/xfs_trans_ail.c
> > @@ -494,7 +494,7 @@ xfs_ail_worker(
> >  
> >     if (push_xfsbufd) {
> >             /* we've got delayed write buffers to flush */
> > -           wake_up_process(mp->m_ddev_targp->bt_task);
> > +           flush_delayed_work(&mp->m_ddev_targp->bt_delwrite_work);
> 
> This is a huge change in behaviour.  wake_up_process just kicks the
> thread to wakeup from sleep as soon as the schedule selects it, while
> flush_delayed_work does not only queue a pending delayed work, but also
> waits for it to finish.

Which is precisely what I want here - to wait for all the delwri
buffers that were promoted to be submitted before continuing
onwards.  This makes the scanning algorithm self throttling -
instead of simply pushing the buffers to the delwri queue and
kicking a background thread and hoping it can flush buffers faster
than we can promote them from the AIL, it explicitly pushes the
delwri buffers before the next round of AIL scanning. The ensures we
start timely IO on the buffers and don't simple continue to scan the
AIL while we wait for the background thread to send them off to
disk and complete.

IOWs, instead of:

        AIL                     bufd
        promote
        ....
        promote
        wakeup
        short sleep
                                woken
                                sort
                                dispatch
                                ....

<sometime later, maybe before, during or after xfsbufd has run>

        promote
        .....
        promote
        wakeup
        short sleep
                                woken
                                sort
                                dispatch
                                ....

Where we *hope* the short sleep in the AIL processing is long enough
to avoid repeated scanning of the AIL while the queued IO is
dispatched. we end up with:

        AIL                     bufd
        promote
        ....
        promote
        flush_work
                                sort
                                dispatch
        short sleep

        promote
        ....
        promote
        flush_work
                                sort
                                dispatch
        short sleep

Which is much more controlled and means that the short sleep that
that the AIL processing does actually gives time for IO completions
to occur before continuing. It means that dispatch of IO from the
AIL is throttled to the rate of device congestion as it now waits
for the IO dispatch to complete instead of just sholving as much Io
as possible into the bufd queue.

FWIW, if we move to building a direct IO buffer list in the AIL as
we were recently discussing, this is -exactly- the IO dispatch
patterns and delays that we will get from the AIL....

Cheers,

Dave.

-- 
Dave Chinner
david@xxxxxxxxxxxxx

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