From: Mike Rapoport <rppt@kernel.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: "Kirill A. Shutemov" <kirill@shutemov.name>,
Al Viro <viro@zeniv.linux.org.uk>,
Peter Zijlstra <peterz@infradead.org>,
Nathan Chancellor <nathan@kernel.org>,
Nick Desaulniers <ndesaulniers@google.com>,
Jeff Layton <jlayton@kernel.org>,
Ilya Dryomov <idryomov@gmail.com>,
ceph-devel@vger.kernel.org,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Matthew Wilcox <willy@infradead.org>,
clang-built-linux <llvm@lists.linux.dev>,
Dave Hansen <dave.hansen@linux.intel.com>
Subject: Re: Simplify load_unaligned_zeropad() (was Re: [GIT PULL] Ceph updates for 5.20-rc1)
Date: Mon, 15 Aug 2022 11:26:51 +0300 [thread overview]
Message-ID: <YvoDS+fHAe931JPi@kernel.org> (raw)
In-Reply-To: <CAHk-=whSGBmH7zKvD-=qJLkWPSGZo1cM7GyLH=8cuide7+ri_Q@mail.gmail.com>
On Sun, Aug 14, 2022 at 08:43:09PM -0700, Linus Torvalds wrote:
> On Sun, Aug 14, 2022 at 3:59 PM Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> >
> > If TDX has problems with it, then TDX needs to be fixed. And it's
> > simple enough - just make sure you have a guard page between any
> > kernel RAM mapping and whatever odd crazy page.
>
> .. thinking about this more, I thought we had already done that in the
> memory initialization code - ie make sure that we always leave a gap
> between any page we mark and any IO memory after it.
>
> But it's possible that I'm confused with the IO window allocation
> code, which does the reverse (ie actively try to avoid starting
> allocations close to the end-of-RAM because there is often
> undocumented stolen memory there)
>
> I'd much rather lose one page from the page allocator at the end of a
> RAM region than lose the ability to do string word operations.
>
> Of course, it's also entirely possible that even if my memory about us
> already trying to do that is right (which it might not be), we might
> also have lost that whole thing over time, since we've had a lot of
> updates to the bootmem/memblock setup.
We don't create gaps in the memory initialization code, everything that's
E820_TYPE_RAM goes in the end to the page allocator with exception of
partial pages. And this didn't change in the last few years.
> Linus
--
Sincerely yours,
Mike.
next prev parent reply other threads:[~2022-08-15 8:27 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-14 21:14 Simplify load_unaligned_zeropad() (was Re: [GIT PULL] Ceph updates for 5.20-rc1) Linus Torvalds
2022-08-14 22:54 ` Kirill A. Shutemov
2022-08-14 22:59 ` Linus Torvalds
2022-08-15 3:43 ` Linus Torvalds
2022-08-15 4:12 ` Kirill A. Shutemov
2022-08-24 19:02 ` Dave Hansen
2022-08-15 8:26 ` Mike Rapoport [this message]
2022-08-15 7:17 ` Peter Zijlstra
2022-08-15 15:58 ` Linus Torvalds
2022-08-15 17:53 ` Peter Zijlstra
2022-08-15 20:09 ` Peter Zijlstra
2022-08-15 22:49 ` Linus Torvalds
2022-08-16 8:02 ` Peter Zijlstra
2022-08-16 17:57 ` Linus Torvalds
2022-08-17 7:45 ` Peter Zijlstra
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=YvoDS+fHAe931JPi@kernel.org \
--to=rppt@kernel.org \
--cc=ceph-devel@vger.kernel.org \
--cc=dave.hansen@linux.intel.com \
--cc=idryomov@gmail.com \
--cc=jlayton@kernel.org \
--cc=kirill@shutemov.name \
--cc=linux-kernel@vger.kernel.org \
--cc=llvm@lists.linux.dev \
--cc=nathan@kernel.org \
--cc=ndesaulniers@google.com \
--cc=peterz@infradead.org \
--cc=torvalds@linux-foundation.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 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.