From: Mark Tinguely <tinguely@sgi.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: xfs@oss.sgi.com
Subject: Re: [patch 04/12] xfs: cleanup xfs_log_space_wake
Date: Wed, 25 Jan 2012 13:09:12 -0600 [thread overview]
Message-ID: <4F205358.5070702@sgi.com> (raw)
In-Reply-To: <20120125161041.GB8360@infradead.org>
On 01/25/12 10:10, Christoph Hellwig wrote:
> On Mon, Jan 23, 2012 at 01:22:22PM -0600, Mark Tinguely wrote:
>> On 01/-10/63 13:59, Christoph Hellwig wrote:
>>> Remove the now unused opportunistic parameter, and use the the
>>> xlog_writeq_wake and xlog_reserveq_wake helpers now that we don't have
>>> to care about the opportunistic wakeups.
>>>
>>> Signed-off-by: Christoph Hellwig<hch@lst.de>
>>
>> Looks good. My only concern is the way that xlog_grant_push_ail()
>> tries to kick start the writing of the log. It seems to me that a
>> combination of very large log requests could plug the log until the
>> next sync.
>
> How exactly?
>
Thanks for giving me enough rope to hang myself :)
I looked at it again and it could plug for a while, but not necessarily
until the next sync.
I was looking at the fact that when the log is full,
xlog_grant_push_ail() will overlap cleaning threshold lsn for a bunch of
requests come in. This is because xlog_grant_push_ail() uses the current
tail when calculating cleaning threshold. This cleaning overlap will
happen until xfs_ail_push() cleans the space and the moves the log tail.
If a (unrealistically) big request sized greater than MAX(log size/4,
256) follows some other requests then the big request determines the
amount cleaned out of the queue. When the space is cleaned out, the
earlier processes waiting for the log are awoken and use up the cleaned
space, and there will not be enough space for the big request. Future
requests will clean up to MAX(their request size, log size/4, 256). This
will not be enough to satisfy the big request at the front of the
request queue. We will have to wait another cleaning cycle for the tail
to move and another log space request but even this big request would
eventually get satisfied.
--Mark Tinguely
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2012-01-25 19:09 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-12 14:13 [patch 00/12] log grant code cleanups Christoph Hellwig
2011-12-12 14:13 ` [patch 01/12] xfs: split tail_lsn assignments from log space wakeups Christoph Hellwig
2012-01-17 18:48 ` Mark Tinguely
2012-01-25 16:09 ` Christoph Hellwig
2012-02-16 18:21 ` Ben Myers
2012-02-17 19:21 ` Christoph Hellwig
2011-12-12 14:13 ` [patch 02/12] xfs: do exact log space wakeups in xlog_ungrant_log_space Christoph Hellwig
2012-01-17 22:42 ` Mark Tinguely
2012-02-16 18:36 ` Ben Myers
2011-12-12 14:13 ` [patch 03/12] xfs: remove xfs_trans_unlocked_item Christoph Hellwig
2012-01-23 14:31 ` Mark Tinguely
2012-02-16 18:51 ` Ben Myers
2011-12-12 14:13 ` [patch 04/12] xfs: cleanup xfs_log_space_wake Christoph Hellwig
2012-01-23 19:22 ` Mark Tinguely
2012-01-25 16:10 ` Christoph Hellwig
2012-01-25 19:09 ` Mark Tinguely [this message]
2012-01-26 16:13 ` Mark Tinguely
2012-01-26 22:12 ` Dave Chinner
2012-02-16 19:06 ` Ben Myers
2011-12-12 14:13 ` [patch 05/12] xfs: remove log space waitqueues Christoph Hellwig
2012-01-23 21:58 ` Mark Tinguely
2011-12-12 14:13 ` [patch 06/12] xfs: add the xlog_grant_head structure Christoph Hellwig
2012-01-24 15:35 ` Mark Tinguely
2012-02-16 20:23 ` Ben Myers
2011-12-12 14:13 ` [patch 07/12] xfs: add xlog_grant_head_init Christoph Hellwig
2012-01-24 15:43 ` Mark Tinguely
2012-02-16 20:29 ` Ben Myers
2011-12-12 14:13 ` [patch 08/12] xfs: add xlog_grant_head_wake_all Christoph Hellwig
2012-01-24 15:46 ` Mark Tinguely
2012-02-16 20:44 ` Ben Myers
2011-12-12 14:13 ` [patch 09/12] xfs: share code for grant head waiting Christoph Hellwig
2012-01-24 18:10 ` Mark Tinguely
2012-02-16 20:51 ` Ben Myers
2011-12-12 14:13 ` [patch 10/12] xfs: shared code for grant head wakeups Christoph Hellwig
2012-01-24 18:37 ` Mark Tinguely
2012-02-16 21:08 ` Ben Myers
2011-12-12 14:13 ` [patch 11/12] xfs: share code for grant head availability checks Christoph Hellwig
2012-01-24 18:53 ` Mark Tinguely
2012-02-16 21:25 ` Ben Myers
2012-02-17 2:41 ` Dave Chinner
2011-12-12 14:13 ` [patch 12/12] xfs: split and cleanup xfs_log_reserve Christoph Hellwig
2012-02-16 21:36 ` Ben Myers
2012-02-19 21:16 ` Christoph Hellwig
2012-02-16 6:16 ` [patch 00/12] log grant code cleanups Dave Chinner
2012-02-17 18:00 ` Christoph Hellwig
2012-02-16 21:46 ` Ben Myers
2012-02-19 21:17 ` Christoph Hellwig
2012-02-20 21:59 ` Ben Myers
-- strict thread matches above, loose matches on Subject: below --
2012-02-20 2:31 [PATCH 00/12] log grant code cleanups V2 Christoph Hellwig
2012-02-20 2:31 ` [PATCH 04/12] xfs: cleanup xfs_log_space_wake Christoph Hellwig
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4F205358.5070702@sgi.com \
--to=tinguely@sgi.com \
--cc=hch@infradead.org \
--cc=xfs@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox