linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Jan Kara <jack@suse.cz>
Cc: linux-fsdevel@vger.kernel.org, Surbhi Palande <csurbhi@gmail.com>,
	Kamal Mostafa <kamal@canonical.com>,
	Eric Sandeen <sandeen@sandeen.net>,
	LKML <linux-kernel@vger.kernel.org>,
	xfs@oss.sgi.com, Christoph Hellwig <hch@infradead.org>,
	Dave Chinner <dchinner@redhat.com>,
	linux-ext4@vger.kernel.org
Subject: Re: [PATCH 1/4] fs: Improve filesystem freezing handling
Date: Fri, 13 Jan 2012 12:26:43 +1100	[thread overview]
Message-ID: <20120113012643.GF2806@dastard> (raw)
In-Reply-To: <1326331253-6497-2-git-send-email-jack@suse.cz>

On Thu, Jan 12, 2012 at 02:20:50AM +0100, Jan Kara wrote:
> + *
> + * Decrement number of writers to the filesystem and wake up possible
> + * waiters wanting to freeze the filesystem.
> + */
> +void sb_end_write(struct super_block *sb)
> +{
> +#ifdef CONFIG_SMP
> +	this_cpu_dec(sb->s_writers);
> +#else
> +	preempt_disable();
> +	sb->s_writers--;
> +	preempt_enable();
> +#endif

I really dislike this type of open coded per-cpu counter
implementation. I can't see that there is no good reason to use it
over percpu_counters here which abstract all this mess away.

i.e. it is relatively rare that the per-cpu count will nest
greater than the percpu_counter batch size (needs more than 32
concurrent blocked active writes per CPU), so there is no
significant overhead to using the percpu_counters here.

Indeed, if there are that many blocked writes per CPU, then the
overhead of an occasional global counter update is going to be lost
in the noise of everything else that is going on.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

  parent reply	other threads:[~2012-01-13  1:26 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-12  1:20 [PATCH 0/4] Fix filesystem freezing Jan Kara
2012-01-12  1:20 ` [PATCH 1/4] fs: Improve filesystem freezing handling Jan Kara
2012-01-12 19:53   ` Andreas Dilger
2012-01-12 20:07     ` Jan Kara
2012-01-12 22:57   ` Eric Sandeen
2012-01-12 23:15     ` Jan Kara
2012-01-13  1:26   ` Dave Chinner [this message]
2012-01-13 10:12     ` Jan Kara
2012-01-12  1:20 ` [PATCH 2/4] vfs: Protect write paths by sb_start_write - sb_end_write Jan Kara
2012-01-12 19:56   ` Andreas Dilger
2012-01-12 20:11     ` Jan Kara
2012-01-12  1:20 ` [PATCH 3/4] ext4: Protect ext4_page_mkwrite with " Jan Kara
2012-01-12  1:20 ` [PATCH 4/4] xfs: Protect xfs_file_aio_write() " Jan Kara
2012-01-12 21:29   ` Al Viro
2012-01-12 21:36     ` Jan Kara
2012-01-12  2:48 ` [PATCH 0/4] Fix filesystem freezing Dave Chinner
2012-01-12 11:30   ` Jan Kara
2012-01-13  0:09     ` Dave Chinner
2012-01-13 11:07       ` Jan Kara
2012-01-12 20:48 ` Ted Ts'o
2012-01-12 21:38   ` Jan Kara

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=20120113012643.GF2806@dastard \
    --to=david@fromorbit.com \
    --cc=csurbhi@gmail.com \
    --cc=dchinner@redhat.com \
    --cc=hch@infradead.org \
    --cc=jack@suse.cz \
    --cc=kamal@canonical.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sandeen@sandeen.net \
    --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;
as well as URLs for NNTP newsgroup(s).