linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: William Kucharski <william.kucharski@oracle.com>
To: David Hildenbrand <david@redhat.com>
Cc: Zach O'Keefe <zokeefe@google.com>,
	Mike Kravetz <mike.kravetz@oracle.com>,
	Peter Xu <peterx@redhat.com>, Rik van Riel <riel@surriel.com>,
	Mike Rapoport <rppt@kernel.org>, Linux-MM <linux-mm@kvack.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: THP backed thread stacks
Date: Sat, 11 Mar 2023 12:24:58 +0000	[thread overview]
Message-ID: <F5DD5318-F762-4FE8-AF1D-7D9AC6A73D39@oracle.com> (raw)
In-Reply-To: <9f44de08-b484-baa7-80c8-0a02a7abb717@redhat.com>


> On Mar 10, 2023, at 04:25, David Hildenbrand <david@redhat.com> wrote:
> 
> On 10.03.23 02:40, William Kucharski wrote:
>>> On Mar 9, 2023, at 17:05, Zach O'Keefe <zokeefe@google.com> wrote:
>>> 
>>>> I think the hugepage alignment in their environment was somewhat luck.
>>>> One suggestion made was to change stack size to avoid alignment and
>>>> hugepage usage.  That 'works' but seems kind of hackish.
>>> 
>>> That was my first thought, if the alignment was purely due to luck,
>>> and not somebody manually specifying it. Agreed it's kind of hackish
>>> if anyone can get bit by this by sheer luck.
>> I don't agree it's "hackish" at all, but I go more into that below.
>>> 
>>>> Also, David H pointed out the somewhat recent commit to align sufficiently
>>>> large mappings to THP boundaries.  This is going to make all stacks huge
>>>> page aligned.
>>> 
>>> I think that change was reverted by Linus in commit 0ba09b173387
>>> ("Revert "mm: align larger anonymous mappings on THP boundaries""),
>>> until it's perf regressions were better understood -- and I haven't
>>> seen a revamp of it.
>> It's too bad it was reverted, though I understand the concerns regarding it.
>> From my point of view, if an address is properly aligned and a caller is
>> asking for 2M+ to be mapped, it's going to be advantageous from a purely
>> system-focused point of view to do that mapping with a THP. 
> 
> Just noting that, if user space requests multiple smaller mappings, and the kernel decides to all place them in the same PMD, all VMAs might get merged and you end up with a properly aligned VMA where khugepaged would happily place a THP.
> 
> That case is, of course, different to the "user space asks for 2M+" mapping case, but from khugepaged perspective they might look alike -- and it might be unclear if a THP is valuable or not (IOW maybe that THP could be better used somewhere else).

That's a really, really good point.

My general philosophy on the subject (if the address is aligned and the caller is asking for a THP-sized allocation, why not map it with a THP if you can) kind of falls apart when it's the system noticing it can coalesce a bunch of smaller allocations into one THP via khugepaged.

Arguably it's the difference between the caller knowing it's asking for something THP-sized on its behalf and the system deciding to remap a bunch of disparate mappings using a THP because _it_ can.

If we were to say allow a caller's request for a THP-sized allocation/mapping take priority over those from khugepaged, it would not only be a major vector for abuse, it would also lead to completely indeterminate behavior ("When I start my browser after a reboot I get a bunch of THPs, but after the system's been up for a few weeks, I don't, how come?")

I don't have a good answer here.

    -- Bill

  reply	other threads:[~2023-03-11 12:27 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-06 23:57 THP backed thread stacks Mike Kravetz
2023-03-07  0:15 ` Peter Xu
2023-03-07  0:40   ` Mike Kravetz
2023-03-08 19:02     ` Mike Kravetz
2023-03-09 22:38       ` Zach O'Keefe
2023-03-09 23:33         ` Mike Kravetz
2023-03-10  0:05           ` Zach O'Keefe
2023-03-10  1:40             ` William Kucharski
2023-03-10 11:25               ` David Hildenbrand
2023-03-11 12:24                 ` William Kucharski [this message]
     [not found]                 ` <20230312005549.2609-1-hdanton@sina.com>
2023-03-12  4:39                   ` William Kucharski
2023-03-10 22:02             ` Yang Shi
2023-03-07 10:10 ` David Hildenbrand
2023-03-07 19:02   ` Mike Kravetz
2023-03-07 13:36 ` Mike Rapoport
2023-03-17 17:52 ` Matthew Wilcox
2023-03-17 18:46   ` Mike Kravetz
2023-03-20 11:12     ` David Hildenbrand
2023-03-20 17:46       ` William Kucharski
2023-03-20 17:52         ` David Hildenbrand
2023-03-20 18:06         ` Mike Kravetz
2023-03-18 12:58   ` David Laight

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=F5DD5318-F762-4FE8-AF1D-7D9AC6A73D39@oracle.com \
    --to=william.kucharski@oracle.com \
    --cc=david@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mike.kravetz@oracle.com \
    --cc=peterx@redhat.com \
    --cc=riel@surriel.com \
    --cc=rppt@kernel.org \
    --cc=zokeefe@google.com \
    /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).