From: Keith Busch <kbusch@kernel.org>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: Keith Busch <kbusch@meta.com>, kvm@vger.kernel.org
Subject: Re: [PATCH] vfio/type1: conditional rescheduling while pinning
Date: Fri, 11 Jul 2025 14:40:52 -0600 [thread overview]
Message-ID: <aHF21JIasR_sTq_g@kbusch-mbp> (raw)
In-Reply-To: <20250711141657.16dd6a20.alex.williamson@redhat.com>
On Fri, Jul 11, 2025 at 02:16:57PM -0600, Alex Williamson wrote:
> On Wed, 9 Jul 2025 14:18:58 -0600
> Keith Busch <kbusch@kernel.org> wrote:
> > I think I'm back to needing a cond_resched(). I'm finding too many user
> > space programs, including qemu, for various reasons do not utilize
> > hugepage faults, and we're ultimately locking up a cpu for long enough
> > to cause other nasty side effects, like OOM due to blocked rcu free
> > callbacks. As preferable as it is to get everything aligned to use the
> > faster faults, I don't think the kernel should depend on that to prevent
> > prolonged cpu lockups. What do you think?
>
> I'm not opposed to adding a cond_resched, but I'll also note that Peter
> Xu has been working on a series that tries to get the right mapping
> alignment automatically. It's still a WIP, but it'd be good to know if
> that resolves the remaining userspace issues you've seen or we're still
> susceptible to apps that aren't even trying to use THP:
>
> https://lore.kernel.org/all/20250613134111.469884-1-peterx@redhat.com/
Yes, I saw that series and included that for testing as well.
But I'm finding many machines have a transparent_hugepage enabled policy
set to "never" due to some problems THP usage caused with other hardware
(CXL, I think). I'm trying to get these to use "madvise" instead, but
that's causing other performance regressions for some tests.
prev parent reply other threads:[~2025-07-11 20:40 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-12 22:52 [PATCH] vfio/type1: conditional rescheduling while pinning Keith Busch
2025-03-17 21:44 ` Alex Williamson
2025-03-17 22:30 ` Keith Busch
2025-03-17 22:53 ` Alex Williamson
2025-03-19 15:47 ` Keith Busch
2025-03-19 18:17 ` Alex Williamson
2025-03-19 18:34 ` Keith Busch
2025-03-19 22:13 ` Keith Busch
2025-07-09 20:18 ` Keith Busch
2025-07-11 20:16 ` Alex Williamson
2025-07-11 20:40 ` Keith Busch [this message]
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=aHF21JIasR_sTq_g@kbusch-mbp \
--to=kbusch@kernel.org \
--cc=alex.williamson@redhat.com \
--cc=kbusch@meta.com \
--cc=kvm@vger.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 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.