linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Christoph Lameter <cl@linux.com>
Cc: Waiman Long <waiman.long@hpe.com>, Tejun Heo <tj@kernel.org>,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	Jan Kara <jack@suse.com>, Jeff Layton <jlayton@poochiereds.net>,
	"J. Bruce Fields" <bfields@fieldses.org>,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	Ingo Molnar <mingo@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Andi Kleen <andi@firstfloor.org>,
	Dave Chinner <dchinner@redhat.com>,
	Boqun Feng <boqun.feng@gmail.com>,
	Scott J Norton <scott.norton@hpe.com>,
	Douglas Hatch <doug.hatch@hpe.com>
Subject: Re: [PATCH v3 1/4] lib/dlock-list: Distributed and lock-protected lists
Date: Thu, 21 Jul 2016 11:49:43 +1000	[thread overview]
Message-ID: <20160721014943.GC12670@dastard> (raw)
In-Reply-To: <alpine.DEB.2.20.1607201945540.24483@east.gentwo.org>

On Wed, Jul 20, 2016 at 07:48:13PM -0500, Christoph Lameter wrote:
> On Wed, 20 Jul 2016, Waiman Long wrote:
> 
> > Christoph, are you OK with Tejun's request to revert the name back to
> > percpu_list? Or do you still think the current name is better?
> 
> The percpu structure contains a spinlock and may be remotely accessed? You
> are aware that other percpu variables that share the same cacheline will
> be negatively impacted by accesses from other processors?
> 
> The role of percpu areas are to have memory areas where the code can
> expect that cachelines are exclusively there for that processor.
> 
> How frequent are the remote accesses? If this is rare then ok.

Remote access will be the common case on traversal and removal from
the superblock inode list.

Under memory reclaim, the access should at least be from
a CPU on the same node (as inode reclaim is NUMA aware). However,
any other inode eviction event (e.g. inode unlink) removing it from
the sb list will essentially be from a random CPU.

Traversals (such as from the sync code, or cache invalidations) will
run on a single CPU, so alomst all access from them will be be
remote.

So it's really only a per-cpu structure for list addition....

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

  parent reply	other threads:[~2016-07-21  1:49 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-15 17:39 [PATCH v3 0/4] vfs: Use dlock list for SB's s_inodes list Waiman Long
2016-07-15 17:39 ` [PATCH v3 1/4] lib/dlock-list: Distributed and lock-protected lists Waiman Long
2016-07-18 23:38   ` Tejun Heo
2016-07-19 18:42     ` Waiman Long
2016-07-19 19:23       ` Tejun Heo
2016-07-20 19:53         ` Waiman Long
2016-07-20 22:02         ` Waiman Long
2016-07-20 22:15       ` Waiman Long
2016-07-21  0:48         ` Christoph Lameter
2016-07-21  1:36           ` Waiman Long
2016-07-21  1:49           ` Dave Chinner [this message]
2016-07-22 20:43       ` Waiman Long
2016-07-19  5:00   ` Al Viro
2016-07-19 19:01     ` Waiman Long
2016-07-15 17:39 ` [PATCH v3 2/4] fsnotify: Simplify inode iteration on umount Waiman Long
2016-07-15 17:39 ` [PATCH v3 3/4] vfs: Remove unnecessary list_for_each_entry_safe() variants Waiman Long
2016-07-15 17:39 ` [PATCH v3 4/4] vfs: Use dlock list for superblock's inode list Waiman Long
2016-07-19  5:23   ` Al Viro
2016-07-19 18:35     ` Tejun Heo
2016-07-19 19:07     ` Waiman Long

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=20160721014943.GC12670@dastard \
    --to=david@fromorbit.com \
    --cc=andi@firstfloor.org \
    --cc=bfields@fieldses.org \
    --cc=boqun.feng@gmail.com \
    --cc=cl@linux.com \
    --cc=dchinner@redhat.com \
    --cc=doug.hatch@hpe.com \
    --cc=jack@suse.com \
    --cc=jlayton@poochiereds.net \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=scott.norton@hpe.com \
    --cc=tj@kernel.org \
    --cc=viro@zeniv.linux.org.uk \
    --cc=waiman.long@hpe.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).