linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jan Kara <jack@suse.cz>
To: Amir Goldstein <amir73il@gmail.com>
Cc: Jan Kara <jack@suse.cz>, Al Viro <viro@zeniv.linux.org.uk>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>
Subject: Re: [PATCH] fs: group frequently accessed fields of struct super_block together
Date: Fri, 19 Oct 2018 14:02:36 +0200	[thread overview]
Message-ID: <20181019120236.GF17214@quack2.suse.cz> (raw)
In-Reply-To: <CAOQ4uxiK9D5eyQBpQRYRXaTsw2nqgcb2gFDg7DH1DGg_jC-sNQ@mail.gmail.com>

On Thu 18-10-18 15:48:04, Amir Goldstein wrote:
> On Thu, Oct 18, 2018 at 3:11 PM Jan Kara <jack@suse.cz> wrote:
> >
> > On Thu 18-10-18 14:22:55, Amir Goldstein wrote:
> > > Kernel test robot reported [1] a 6% performance regression in a
> > > concurrent unlink(2) workload on commit 60f7ed8c7c4d ("fsnotify: send
> > > path type events to group with super block marks").
> > >
> > > The performance test was run with no fsnotify marks at all on the
> > > data set, so the only extra instructions added by the offending
> > > commit are tests of the super_block fields s_fsnotify_{marks,mask}
> > > and these tests happen on almost every single inode access.
> > >
> > > When adding those fields to the super_block struct, we did not give much
> > > thought of placing them on a hot cache lines (we just placed them at the
> > > end of the struct).
> > >
> > > Re-organize struct super_block to try and keep some frequently accessed
> > > fields on the same cache line.
> > >
> > > Move the frequently accessed fields s_fsnotify_{marks,mask} near the
> > > frequently accessed fields s_fs_info,s_time_gran, while filling a 64bit
> > > alignment hole after s_time_gran.
> > >
> > > Move the seldom accessed fields s_id,s_uuid,s_max_links,s_mode near the
> > > seldom accessed fields s_vfs_rename_mutex,s_subtype.
> > >
> > > Rong Chen confirmed that this patch solved the reported problem.
> >
> > ...
> >
> > > +     /* START frequently accessed fields block */
> >
> > The movement of struct entries is fine. But I don't think the comments
> > about START / END of sections are really useful there are much more entries
> > in the struct which are frequently or seldomly accesses and furthemore it's
> > going to depend on the workload.
> >
> > Also how are you going to make sure the entries are going to fall into the
> > same cache line? Different architectures are going to have different
> > cacheline size and also the offset is going to be different... OTOH
> > s_writers is usually relatively frequently accessed so probably it doesn't
> > matter too much.
> >
> > So maybe just change the comment to something like:
> >
> >         /*
> >          * Keep s_fs_info, s_time_gran, s_fsnotify_mask, and
> >          * s_fsnotify_marks together for cache efficiency. They are frequently
> >          * accessed and rarely modified.
> >          */
> >
> 
> Yes, fine by me. I am assuming you are making those changes on apply.

Yes, I can. I'll push the patch to my tree so that it can go with other
fsnotify changes during the merge window.

> I was going to include s_writers and s_dquot in the "frequently accessed block",
> they are also quite frequently accessed, but only on write access patterns, but
> those fields are too big to try to optimize cache lines, so I kept
> them out of the
> comment.

Yeah, we do have ____cacheline_aligned_in_smp directive when you want to
force cacheline alignment but I don't think it is warranted here.

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

      reply	other threads:[~2018-10-19 20:08 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-18 11:22 [PATCH] fs: group frequently accessed fields of struct super_block together Amir Goldstein
2018-10-18 12:11 ` Jan Kara
2018-10-18 12:48   ` Amir Goldstein
2018-10-19 12:02     ` Jan Kara [this message]

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=20181019120236.GF17214@quack2.suse.cz \
    --to=jack@suse.cz \
    --cc=amir73il@gmail.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=viro@zeniv.linux.org.uk \
    /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).