All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <jens.axboe@oracle.com>
To: Artem Bityutskiy <dedekind1@gmail.com>
Cc: Jamie Lokier <jamie@shareable.org>,
	linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	chris.mason@oracle.com, david@fromorbit.com, hch@infradead.org,
	akpm@linux-foundation.org, jack@suse.cz,
	yanmin_zhang@linux.intel.com, richard@rsk.demon.co.uk,
	damien.wyart@free.fr, fweisbec@gmail.com, Alan.Brunelle@hp.com
Subject: Re: [PATCH 05/10] writeback: support > 1 flusher thread per bdi
Date: Mon, 6 Jul 2009 17:43:45 +0200	[thread overview]
Message-ID: <20090706154345.GT23611@kernel.dk> (raw)
In-Reply-To: <4A520608.7070707@gmail.com>

On Mon, Jul 06 2009, Artem Bityutskiy wrote:
> Jamie Lokier wrote:
>> Artem Bityutskiy wrote:
>>> Jens Axboe wrote:
>>>> +static void bdi_queue_work(struct backing_dev_info *bdi, struct bdi_work
>>>> *work)
>>>> +{
>>>> +	if (work) {
>>>> +		work->seen = bdi->wb_mask;
>>>> +		BUG_ON(!work->seen);
>>>> +		atomic_set(&work->pending, bdi->wb_cnt);
>>>> +		BUG_ON(!bdi->wb_cnt);
>>>> +
>>>> +		/*
>>>> +		 * Make sure stores are seen before it appears on the list
>>>> +		 */
>>>> +		smp_mb();
>>>> +
>>>> +		spin_lock(&bdi->wb_lock);
>>>> +		list_add_tail_rcu(&work->list, &bdi->work_list);
>>>> +		spin_unlock(&bdi->wb_lock);
>>>> +	}
>>> Doesn't spin_lock() include an implicit memory barrier?
>>> After &bdi->wb_lock is acquired, it is guaranteed that all
>>> memory operations are finished.
>>
>> I'm pretty sure spin_lock() is an "acquire" barrier, which just guarantees
>> loads/stores after the spin_lock() are done after taking the lock.
>>
>> It doesn't guarantee anything about loads/stores before the spin_lock().
>
> Right, but comment says memops should be flushed before the
> list is changed.

The comment says that the _above_ stores should be seen before it
appears on the list, it doesn't say anything about the list itself. What
matters is that the ->seen/pending must be fully visible before it
appears on the list. A spin_lock() doesn't guarentee that, and the bdi
thread could even see the work before the spin_unlock() is started.

-- 
Jens Axboe


  reply	other threads:[~2009-07-06 15:44 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-25 10:41 [PATCH 0/10] Per-bdi writeback flusher threads v12 Jens Axboe
2009-06-25 10:41 ` [PATCH 01/10] writeback: move dirty inodes from super_block to backing_dev_info Jens Axboe
2009-06-25 10:41 ` [PATCH 02/10] writeback: switch to per-bdi threads for flushing data Jens Axboe
2009-07-06 12:55   ` Artem Bityutskiy
2009-07-06 12:55     ` Artem Bityutskiy
2009-07-06 13:13     ` Jens Axboe
2009-07-06 13:26       ` Artem Bityutskiy
2009-07-06 13:26         ` Artem Bityutskiy
2009-07-07 15:27   ` Artem Bityutskiy
2009-07-07 15:27     ` Artem Bityutskiy
2009-07-08  0:57     ` Zhang, Yanmin
2009-07-08  4:47       ` Artem Bityutskiy
2009-07-08  4:47         ` Artem Bityutskiy
2009-06-25 10:41 ` [PATCH 03/10] writeback: get rid of pdflush completely Jens Axboe
2009-06-25 10:41 ` [PATCH 04/10] writeback: separate the flushing state/task from the bdi Jens Axboe
2009-06-25 10:41 ` [PATCH 05/10] writeback: support > 1 flusher thread per bdi Jens Axboe
2009-07-06 12:18   ` Artem Bityutskiy
2009-07-06 12:22     ` Jens Axboe
2009-07-06 13:37   ` Artem Bityutskiy
2009-07-06 13:49     ` Jamie Lokier
2009-07-06 14:11       ` Artem Bityutskiy
2009-07-06 14:11         ` Artem Bityutskiy
2009-07-06 15:43         ` Jens Axboe [this message]
2009-06-25 10:41 ` [PATCH 06/10] writeback: allow sleepy exit of default writeback task Jens Axboe
2009-06-25 10:42 ` [PATCH 07/10] writeback: add some debug inode list counters to bdi stats Jens Axboe
2009-06-25 10:42 ` [PATCH 08/10] writeback: add name to backing_dev_info Jens Axboe
2009-06-25 10:42 ` [PATCH 09/10] writeback: check for registered bdi in flusher add and inode dirty Jens Axboe
2009-06-25 10:42 ` [PATCH 10/10] writeback: use spin_trylock() in bdi_writeback_all() for WB_SYNC_NONE Jens Axboe
2009-06-29  8:43 ` [PATCH 0/10] Per-bdi writeback flusher threads v12 Zhang, Yanmin
  -- strict thread matches above, loose matches on Subject: below --
2009-08-31 12:14 [PATCH 0/10] Per-bdi writeback flusher threads v14 Jens Axboe
2009-08-31 12:14 ` [PATCH 05/10] writeback: support > 1 flusher thread per bdi Jens Axboe
2009-08-31 13:01   ` Christoph Hellwig
2009-08-31 17:32     ` Jens Axboe
2009-06-17 11:07 [PATCH 0/10] Per-bdi writeback flusher threads v11 Jens Axboe
2009-06-17 11:07 ` [PATCH 05/10] writeback: support > 1 flusher thread per bdi Jens Axboe

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=20090706154345.GT23611@kernel.dk \
    --to=jens.axboe@oracle.com \
    --cc=Alan.Brunelle@hp.com \
    --cc=akpm@linux-foundation.org \
    --cc=chris.mason@oracle.com \
    --cc=damien.wyart@free.fr \
    --cc=david@fromorbit.com \
    --cc=dedekind1@gmail.com \
    --cc=fweisbec@gmail.com \
    --cc=hch@infradead.org \
    --cc=jack@suse.cz \
    --cc=jamie@shareable.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=richard@rsk.demon.co.uk \
    --cc=yanmin_zhang@linux.intel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.