From: Eric Dumazet <eric.dumazet@gmail.com>
To: Dave Chinner <david@fromorbit.com>
Cc: 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: Sat, 16 Oct 2010 12:27:32 +0200 [thread overview]
Message-ID: <1287224852.2799.130.camel@edumazet-laptop> (raw)
In-Reply-To: <20101016100441.GP4681@dastard>
Le samedi 16 octobre 2010 à 21:04 +1100, Dave Chinner a écrit :
> get_nr_inodes_unused() is called on every single shrinker call. i.e.
> for every 128 inodes we attempt to reclaim. Given that I'm seeing
> inode reclaim rate in the order of a million per second on a 8p box,
> that meets your criteria for using the generic percpu counter
> infrastructure.
>
> Also, get_nr_inodes() is also called by get_nr_dirty_inodes(), which is
> called by the high level inode writeback code, so will typically be
> called in the order of tens of times per second, and the number of
> calls increased depending on the number of filesystems that are
> active. It's still much higher frequency than your "cat
> /proc/sys/fs/inode-nr" example indicates it might be called.
>
> So I'd say that by your reasoning, the choice of using the generic
> percpu counters is the right one to make.
You missed one thing :
In cases you mention, you want a precise count (aka
percpu_counter_sum_positive()), not the approximate one (aka
percpu_counter_read_positive()).
The only difference is then the possible/online cpu loop difference.
I am saying :
No need to maintain an approximate counter if we dont _read_ it, ever.
Andrew answer : Eric, cant you implement this generically ?
WARNING: multiple messages have this Message-ID (diff)
From: Eric Dumazet <eric.dumazet@gmail.com>
To: Dave Chinner <david@fromorbit.com>
Cc: 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: Sat, 16 Oct 2010 12:27:32 +0200 [thread overview]
Message-ID: <1287224852.2799.130.camel@edumazet-laptop> (raw)
In-Reply-To: <20101016100441.GP4681@dastard>
Le samedi 16 octobre 2010 à 21:04 +1100, Dave Chinner a écrit :
> get_nr_inodes_unused() is called on every single shrinker call. i.e.
> for every 128 inodes we attempt to reclaim. Given that I'm seeing
> inode reclaim rate in the order of a million per second on a 8p box,
> that meets your criteria for using the generic percpu counter
> infrastructure.
>
> Also, get_nr_inodes() is also called by get_nr_dirty_inodes(), which is
> called by the high level inode writeback code, so will typically be
> called in the order of tens of times per second, and the number of
> calls increased depending on the number of filesystems that are
> active. It's still much higher frequency than your "cat
> /proc/sys/fs/inode-nr" example indicates it might be called.
>
> So I'd say that by your reasoning, the choice of using the generic
> percpu counters is the right one to make.
You missed one thing :
In cases you mention, you want a precise count (aka
percpu_counter_sum_positive()), not the approximate one (aka
percpu_counter_read_positive()).
The only difference is then the possible/online cpu loop difference.
I am saying :
No need to maintain an approximate counter if we dont _read_ it, ever.
Andrew answer : Eric, cant you implement this generically ?
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2010-10-16 10:34 UTC|newest]
Thread overview: 62+ 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:04 ` Dave Chinner
2010-10-16 10:27 ` Eric Dumazet [this message]
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
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 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=1287224852.2799.130.camel@edumazet-laptop \
--to=eric.dumazet@gmail.com \
--cc=david@fromorbit.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.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 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.