From: David Hildenbrand <david@redhat.com>
To: Michal Hocko <mhocko@suse.com>, linux-kernel@vger.kernel.org
Cc: amakhalov@vmware.com, cl@linux.com, dennis@kernel.org,
mm-commits@vger.kernel.org, osalvador@suse.de,
stable@vger.kernel.org, tj@kernel.org
Subject: Re: + mm-fix-panic-in-__alloc_pages.patch added to -mm tree
Date: Tue, 9 Nov 2021 09:42:56 +0100 [thread overview]
Message-ID: <af7ab3ce-fed2-1ffc-13a8-f9acbd201841@redhat.com> (raw)
In-Reply-To: <YYozLsIECu0Jnv0p@dhcp22.suse.cz>
On 09.11.21 09:37, Michal Hocko wrote:
> I have opposed this patch http://lkml.kernel.org/r/YYj91Mkt4m8ySIWt@dhcp22.suse.cz
> There was no response to that feedback. I will not go as far as to nack
> it explicitly because pcp allocator is not an area I would nack patches
> but seriously, this issue needs a deeper look rather than a paper over
> patch. I hope we do not want to do a similar thing to all callers of
> cpu_to_mem.
While we could move it into the !HOLES version of cpu_to_mem(), calling
cpu_to_mem() on an offline (and eventually not even present) CPU (with
an offline node) is really a corner case.
Instead of additional runtime overhead for all cpu_to_mem(), my take
would be to just do it for the random special cases. Sure, we can
document that people should be careful when calling cpu_to_mem() on
offline CPUs. But IMHO it's really a corner case.
--
Thanks,
David / dhildenb
next prev parent reply other threads:[~2021-11-09 8:43 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20211108205031.UxDPHBZWa%akpm@linux-foundation.org>
2021-11-09 8:37 ` Michal Hocko
2021-11-09 8:42 ` David Hildenbrand [this message]
2021-11-09 11:00 ` Michal Hocko
2021-11-12 18:20 ` Dennis Zhou
2021-11-15 10:41 ` Michal Hocko
2021-11-15 11:04 ` Alexey Makhalov
2021-11-15 12:58 ` Michal Hocko
2021-11-15 23:11 ` Alexey Makhalov
2021-11-16 3:52 ` Dennis Zhou
2021-11-16 12:30 ` Christoph Lameter
2021-11-16 15:41 ` Michal Hocko
2021-12-14 10:11 ` Michal Hocko
2021-12-14 20:57 ` Andrew Morton
2021-12-15 10:05 ` Michal Hocko
2021-12-15 12:20 ` Michal Hocko
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=af7ab3ce-fed2-1ffc-13a8-f9acbd201841@redhat.com \
--to=david@redhat.com \
--cc=amakhalov@vmware.com \
--cc=cl@linux.com \
--cc=dennis@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mhocko@suse.com \
--cc=mm-commits@vger.kernel.org \
--cc=osalvador@suse.de \
--cc=stable@vger.kernel.org \
--cc=tj@kernel.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
all inboxes | Powered by JetHome®