linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: David Laight <David.Laight@aculab.com>
Cc: David Howells <dhowells@redhat.com>,
	Al Viro <viro@zeniv.linux.org.uk>,  Jens Axboe <axboe@kernel.dk>,
	Christoph Hellwig <hch@list.de>,
	Christian Brauner <christian@brauner.io>,
	 Matthew Wilcox <willy@infradead.org>,
	Jeff Layton <jlayton@kernel.org>,
	 "linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
	 "linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	 "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v3 2/2] iov_iter: Don't deal with iter->copy_mc in memcpy_from_iter_mc()
Date: Thu, 17 Aug 2023 16:38:18 +0200	[thread overview]
Message-ID: <CAHk-=wi4wNm-2OjjhFEqm21xTNTvksmb5N4794isjkp9+FzngA@mail.gmail.com> (raw)
In-Reply-To: <d0232378a64a46659507e5c00d0c6599@AcuMS.aculab.com>

On Thu, 17 Aug 2023 at 10:42, David Laight <David.Laight@aculab.com> wrote:
>
> Although I'm not sure the bit-fields really help.
> There are 8 bytes at the start of the structure, might as well
> use them :-)

Actuallyç I wrote the patch that way because it seems to improve code
generation.

The bitfields are generally all set together as just plain one-time
constants at initialization time, and gcc sees that it's a full byte
write. And the reason 'data_source' is not a bitfield is that it's not
a constant at iov_iter init time (it's an argument to all the init
functions), so having that one as a separate byte at init time is good
for code generation when you don't need to mask bits or anything like
that.

And once initialized, having things be dense and doing all the
compares with a bitwise 'and' instead of doing them as some value
compare again tends to generate good code.

Then being able to test multiple bits at the same time is just gravy
on top of that (ie that whole "remove user_backed, because it's easier
to just test the bit combination").

> OTOH the 'nofault' and 'copy_mc' flags could be put into much
> higher bits of a 32bit value.

Once you start doing that, you often get bigger constants in the code stream.

I didn't do any *extensive* testing of the code generation, but the
stuff I looked at looked good.

               Linus


  reply	other threads:[~2023-08-17 14:38 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-16 12:07 [PATCH v3 0/2] iov_iter: Convert the iterator macros into inline funcs David Howells
2023-08-16 12:07 ` [PATCH v3 1/2] iov_iter: Convert iterate*() to " David Howells
2023-08-16 12:07 ` [PATCH v3 2/2] iov_iter: Don't deal with iter->copy_mc in memcpy_from_iter_mc() David Howells
2023-08-16 12:28   ` David Laight
2023-08-16 13:00   ` David Howells
2023-08-16 14:19     ` David Laight
2023-08-16 18:50       ` Linus Torvalds
2023-08-16 20:35       ` David Howells
2023-08-17  4:18         ` Linus Torvalds
2023-08-17  8:41           ` David Laight
2023-08-17 14:38             ` Linus Torvalds [this message]
2023-08-17 15:16               ` David Laight
2023-08-17 15:31                 ` Linus Torvalds
2023-08-17 16:06                   ` David Laight
2023-08-18 15:19             ` David Howells
2023-08-18 15:42               ` David Laight
2023-08-18 16:48               ` David Howells
2023-08-18 21:39                 ` David Laight
2023-08-18 11:42         ` David Howells
2023-08-18 12:16           ` David Laight
2023-08-18 12:26             ` Matthew Wilcox
2023-08-18 12:41               ` David Laight
2023-08-18 13:33         ` David Howells
2023-08-18 11:39       ` David Howells

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='CAHk-=wi4wNm-2OjjhFEqm21xTNTvksmb5N4794isjkp9+FzngA@mail.gmail.com' \
    --to=torvalds@linux-foundation.org \
    --cc=David.Laight@aculab.com \
    --cc=axboe@kernel.dk \
    --cc=christian@brauner.io \
    --cc=dhowells@redhat.com \
    --cc=hch@list.de \
    --cc=jlayton@kernel.org \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=viro@zeniv.linux.org.uk \
    --cc=willy@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