From: Linus Torvalds <torvalds@linux-foundation.org>
To: David Hildenbrand <david@redhat.com>
Cc: Andreas Gruenbacher <agruenba@redhat.com>,
Alexander Viro <viro@zeniv.linux.org.uk>,
linux-s390 <linux-s390@vger.kernel.org>,
Linux-MM <linux-mm@kvack.org>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
linux-btrfs <linux-btrfs@vger.kernel.org>
Subject: Re: Buffered I/O broken on s390x with page faults disabled (gfs2)
Date: Thu, 10 Mar 2022 10:35:44 -0800 [thread overview]
Message-ID: <CAHk-=wiX1PspWAJ-4Jqk7GHig4B4pJFzPXU7eH2AYtN+iNVAeQ@mail.gmail.com> (raw)
In-Reply-To: <02b20949-82aa-665a-71ea-5a67c1766785@redhat.com>
On Thu, Mar 10, 2022 at 9:13 AM David Hildenbrand <david@redhat.com> wrote:
>
> For the time being, the idea LGTM.
I'll take that as an acked-by, and I think I'll just commit it to my
real tree rather than delay this fix for the next merge window (only
to have it then be marked as stable and applied that wat).
I do agree that we should look at future changes in this area, ranging
from limiting the number of pages to the (I think already pending)
work for arm64 to use an instruction to probe every 128 bytes instead
of on a page basis.
It might even be reasonable to have some hybrid approach that walks
the page tables and faults things in - not quite GUP, not quite
'handle_mm_fault()'.
That said, this is hopefully always going to be the rare case. Yes,
people do IO on "cold" virtual memory, but people doing any
performance work hopefully know that locality (temporal and spatial)
matters not just for the regular CPU data caches, but for pretty much
everything.
Linus
next prev parent reply other threads:[~2022-03-10 18:36 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-07 22:52 Andreas Gruenbacher
2022-03-07 23:18 ` Linus Torvalds
2022-03-08 8:21 ` David Hildenbrand
2022-03-08 8:37 ` David Hildenbrand
2022-03-08 12:11 ` David Hildenbrand
2022-03-08 12:24 ` David Hildenbrand
2022-03-08 13:20 ` Gerald Schaefer
2022-03-08 13:32 ` David Hildenbrand
2022-03-08 14:14 ` Gerald Schaefer
2022-03-08 17:23 ` David Hildenbrand
2022-03-08 17:26 ` Linus Torvalds
2022-03-08 17:40 ` Linus Torvalds
2022-03-08 19:27 ` Linus Torvalds
2022-03-08 20:03 ` Linus Torvalds
2022-03-08 23:24 ` Andreas Gruenbacher
2022-03-09 0:22 ` Linus Torvalds
2022-03-09 18:42 ` Andreas Gruenbacher
2022-03-09 19:08 ` Linus Torvalds
2022-03-09 20:57 ` Andreas Gruenbacher
2022-03-09 21:08 ` Andreas Gruenbacher
2022-03-10 12:13 ` Filipe Manana
2022-03-09 19:21 ` Linus Torvalds
2022-03-09 19:35 ` Andreas Gruenbacher
2022-03-09 20:18 ` Linus Torvalds
2022-03-09 20:36 ` Andreas Gruenbacher
2022-03-09 20:48 ` Linus Torvalds
2022-03-09 20:54 ` Linus Torvalds
2022-03-10 17:13 ` David Hildenbrand
2022-03-10 18:00 ` Andreas Gruenbacher
2022-03-10 18:35 ` Linus Torvalds [this message]
2022-03-10 18:38 ` David Hildenbrand
2022-03-10 18:47 ` Andreas Gruenbacher
2022-03-10 19:22 ` Linus Torvalds
2022-03-10 19:56 ` Linus Torvalds
2022-03-10 20:23 ` Andreas Gruenbacher
2022-03-08 17:47 ` David Hildenbrand
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-=wiX1PspWAJ-4Jqk7GHig4B4pJFzPXU7eH2AYtN+iNVAeQ@mail.gmail.com' \
--to=torvalds@linux-foundation.org \
--cc=agruenba@redhat.com \
--cc=david@redhat.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-s390@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