All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Hemminger <stephen@networkplumber.org>
To: Baruch Even <baruch@weka.io>
Cc: dpdk-dev <dev@dpdk.org>
Subject: Re: Hugepage migration
Date: Mon, 29 May 2023 20:11:24 -0700	[thread overview]
Message-ID: <20230529201124.55f17784@hermes.local> (raw)
In-Reply-To: <CAKye4Qa7HpCTPZ0vOY86JyaDUPPqrsFbpvMqQ=mRHKNNONDNtg@mail.gmail.com>

On Sun, 28 May 2023 23:07:40 +0300
Baruch Even <baruch@weka.io> wrote:

> Hi,
> 
> We found an issue with newer kernels (5.13+) that are found on newer OSes
> (Ubuntu22, Rocky9, Ubuntu20 with kernel 5.15) where a 2M page that was
> allocated for DPDK was migrated (moved into another physical page) when a
> 1G page was allocated.
> 
> From our reading of the kernel commits this started with commit
> ae37c7ff79f1f030e28ec76c46ee032f8fd07607
>     mm: make alloc_contig_range handle in-use hugetlb pages
> 
> This caused what looked like memory corruptions to us and cases where the
> rings were moved from their physical location and communication was no
> longer possible.
> 
> I wanted to ask if anyone else hit this issue and what mitigations are
> available?
> 
> We are currently looking at using a kernel driver to pin the pages but I
> expect that this issue will affect others and that a more general approach
> is needed.
> 
> Thanks,
> Baruch

Report this to upstream kernel regressions, they probably care about it.
Doing a kernel driver hack is overkill, maintenance and long term technical debt problem.

  parent reply	other threads:[~2023-05-30  3:11 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-28 20:07 Hugepage migration Baruch Even
2023-05-30  1:35 ` Stephen Hemminger
2023-05-30 13:51   ` Baruch Even
2023-05-30  3:11 ` Stephen Hemminger [this message]
2023-05-30  8:04 ` Bruce Richardson
2023-05-30 13:53   ` Baruch Even
2023-05-30 15:33     ` Stephen Hemminger

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=20230529201124.55f17784@hermes.local \
    --to=stephen@networkplumber.org \
    --cc=baruch@weka.io \
    --cc=dev@dpdk.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.