linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: Peter Zijlstra <peterz@infradead.org>,
	Eric Dumazet <eric.dumazet@gmail.com>,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 03/19] fs: Convert nr_inodes and nr_unused to per-cpu counters
Date: Sun, 17 Oct 2010 13:16:13 +1100	[thread overview]
Message-ID: <20101017021613.GH32255@dastard> (raw)
In-Reply-To: <20101017011204.GA2207@infradead.org>

On Sat, Oct 16, 2010 at 09:12:04PM -0400, Christoph Hellwig wrote:
> On Sun, Oct 17, 2010 at 12:09:44PM +1100, Dave Chinner wrote:
> > > fwiw, for_each_*_cpu() takes longer than a single jiffy tick on those
> > > machines.
> > 
> > Yes, agreed. I'm not sure we need exact summation for these counters,
> > but I haven't wanted to bring inaccuracies into the code at this
> > point in time. I need to investigate the effect of using the
> > approximate summation values in all the cases they are used.
> 
> Use of the dirty inodes numbers in the writeback code is something
> that does not make much sense.  It was added as an undocumented
> workaround somewhere in the old writeback code, and spread to even
> more sites over time.  I'm pretty sure we don't actually need it,
> but I'm not quite sure what we actually need.

IIRC, it was needed so that we trigger writeback on purely dirty
inodes. i.e. inodes that have no dirty pages and so wbc->nr_to_write
could be changed and not have background writeback abort because
either nr_to_write was zero or wbc->nr_to_write did not change...

A hack, yes, and one that definitely needs to be revisited outside
the scope of this patch set.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

  reply	other threads:[~2010-10-17  2:16 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-16  8:13 Inode Lock Scalability V4 Dave Chinner
2010-10-16  8:13 ` [PATCH 01/19] fs: switch bdev inode bdi's correctly Dave Chinner
2010-10-16  9:30   ` Nick Piggin
2010-10-16 16:31   ` Christoph Hellwig
2010-10-16  8:13 ` [PATCH 02/19] kernel: add bl_list Dave Chinner
2010-10-16  9:51   ` Nick Piggin
2010-10-16 16:32     ` Christoph Hellwig
2010-10-16  8:13 ` [PATCH 03/19] fs: Convert nr_inodes and nr_unused to per-cpu counters Dave Chinner
2010-10-16  8:29   ` Eric Dumazet
2010-10-16 10:04     ` Dave Chinner
2010-10-16 10:27       ` Eric Dumazet
2010-10-16 17:26         ` Peter Zijlstra
2010-10-17  1:09           ` Dave Chinner
2010-10-17  1:12             ` Christoph Hellwig
2010-10-17  2:16               ` Dave Chinner [this message]
2010-10-16  8:13 ` [PATCH 04/19] fs: Implement lazy LRU updates for inodes Dave Chinner
2010-10-16  9:29   ` Nick Piggin
2010-10-16 16:59     ` Christoph Hellwig
2010-10-16 17:29       ` Nick Piggin
2010-10-16 17:34         ` Nick Piggin
2010-10-17  0:47           ` Christoph Hellwig
2010-10-17  0:47         ` Christoph Hellwig
2010-10-17  2:09           ` Nick Piggin
2010-10-17  1:53       ` Dave Chinner
2010-10-16  8:13 ` [PATCH 05/19] fs: inode split IO and LRU lists Dave Chinner
2010-10-16  8:14 ` [PATCH 06/19] fs: Clean up inode reference counting Dave Chinner
2010-10-16  8:14 ` [PATCH 07/19] exofs: use iput() for inode reference count decrements Dave Chinner
2010-10-16  8:14 ` [PATCH 08/19] fs: rework icount to be a locked variable Dave Chinner
2010-10-16  8:14 ` [PATCH 09/19] fs: Factor inode hash operations into functions Dave Chinner
2010-10-16  8:14 ` [PATCH 10/19] fs: Introduce per-bucket inode hash locks Dave Chinner
2010-10-16  8:14 ` [PATCH 11/19] fs: add a per-superblock lock for the inode list Dave Chinner
2010-10-16  8:14 ` [PATCH 12/19] fs: split locking of inode writeback and LRU lists Dave Chinner
2010-10-16  8:14 ` [PATCH 13/19] fs: Protect inode->i_state with the inode->i_lock Dave Chinner
2010-10-16  8:14 ` [PATCH 14/19] fs: introduce a per-cpu last_ino allocator Dave Chinner
2010-10-16  8:14 ` [PATCH 15/19] fs: Make iunique independent of inode_lock Dave Chinner
2010-10-16  8:14 ` [PATCH 16/19] fs: icache remove inode_lock Dave Chinner
2010-10-16  8:14 ` [PATCH 17/19] fs: Reduce inode I_FREEING and factor inode disposal Dave Chinner
2010-10-17  1:30   ` Christoph Hellwig
2010-10-17  2:49     ` Nick Piggin
2010-10-17  4:13       ` Dave Chinner
2010-10-17  4:35         ` Nick Piggin
2010-10-17  5:13           ` Nick Piggin
2010-10-17  6:52             ` Dave Chinner
2010-10-17  7:05               ` Nick Piggin
2010-10-17 23:39                 ` Dave Chinner
2010-10-18 21:27               ` Sage Weil
2010-10-19  3:54                 ` Nick Piggin
2010-10-16  8:14 ` [PATCH 18/19] fs: split __inode_add_to_list Dave Chinner
2010-10-16  8:14 ` [PATCH 19/19] fs: do not assign default i_ino in new_inode Dave Chinner
2010-10-16  9:09   ` Eric Dumazet
2010-10-16 16:35     ` Christoph Hellwig
2010-10-18  9:11       ` Eric Dumazet
2010-10-18 14:48         ` Christoph Hellwig
2010-10-16 17:55 ` Inode Lock Scalability V4 Nick Piggin
2010-10-17  2:47   ` Dave Chinner
2010-10-17  2:55     ` Nick Piggin
2010-10-17  2:57       ` Nick Piggin
2010-10-17  6:10       ` Dave Chinner
2010-10-17  6:34         ` Nick Piggin

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=20101017021613.GH32255@dastard \
    --to=david@fromorbit.com \
    --cc=eric.dumazet@gmail.com \
    --cc=hch@infradead.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peterz@infradead.org \
    /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).