Re: [PATCH v2 08/20] KVM: s390: KVM page table management functions: allocation

Claudio Imbrenda
2025-09-17T14:11:46Z

On Wed, 17 Sep 2025 16:05:44 +0200
Christian Borntraeger <borntraeger@de.ibm.com> wrote:

> Am 17.09.25 um 16:00 schrieb Claudio Imbrenda:
> > On Wed, 17 Sep 2025 15:26:33 +0200
> > Christian Borntraeger <borntraeger@de.ibm.com> wrote:
> >
> >> Am 17.09.25 um 15:11 schrieb Claudio Imbrenda:
> >>> On Wed, 17 Sep 2025 14:30:06 +0200
> >>> Heiko Carstens <hca@linux.ibm.com> wrote:
> >>>
> >>>> On Wed, Sep 17, 2025 at 01:25:56PM +0200, Claudio Imbrenda wrote:
> >>>>> On Wed, 17 Sep 2025 09:27:33 +0200
> >>>>> Heiko Carstens <hca@linux.ibm.com> wrote:
> >>>>>
> >>>>>> On Tue, Sep 16, 2025 at 07:36:44PM +0200, Heiko Carstens wrote:
> >>>>>>> On Tue, Sep 16, 2025 at 07:06:06PM +0200, Christian Borntraeger wrote:
> >>>>>>>>
> >>>>>>>> Am 16.09.25 um 19:05 schrieb Claudio Imbrenda:
> >>>>>>>>
> >>>>>>>>>>> I think GFP_ATOMIC actually gives more guarantees?
> >>>>>>>>>>
> >>>>>>>>>> In real life GFP_ATOMIC can fail, GFP_KERNEL does not.All gfp allocation failures
> >>>>>>>>>> are usually the atomic ones.
> >>>>>>>>>
> >>>>>>>>> interesting... then I guess I need GFP_KERNEL | GFP_ATOMIC ?
> >>>>>>>>
> >>>>>>>> No. ATOMIC always means: can fail.
> >>>>>
> >>>>> my issue is that GFP_KERNEL can sleep, and this allocation is sometimes
> >>>>> called from atomic contexts (e.g. while holding spinlocks)
> >>>>>
> >>>>> the right way to do this would be with mempools, to allocate memory
> >>>>> (and potentially sleep) when we are not in atomic context, and use it
> >>>>> whenever needed. this is on my to-do list for the future, but right now
> >>>>> I'd like to avoid having to refactor a ton of code.
> >>>>
> >>>> I doubt this is accetable even for an intermediate solution. As soon
> >>>> as the host is under memory pressure and starts doing I/O to free up
> >>>> memory, you will end up in -ENOMEM situations for simple guest page
> >>>> allocations.
> >>>>
> >>>> What happens with a guest in such a situation? Is this gracefully
> >>>> handled without that the guest is terminated?
> >>>
> >>> well, we return -ENOMEM to userspace (and qemu will probably kill the
> >>> guest)
> >>>
> >>> but if we can't even allocate 16kB, probably we're already in a pretty
> >>> bad situation
> >>>
> >>> if you think this is not acceptable, I guess I'll have to implement
> >>> mempools
> >>
> >> This is not acceptable. 16k atomic allocations are pretty much guaranteed
> >> to fail after a while of high workload.
> >> What are the callers of this allocation?
> >
> > literally anything that touches the gmap page tables, since we need to
> > hold kvm->mmu_lock, which is an rw spinlock
>
> So how is x86 allocating page table memory. I cant see GPF_ATOMIC or mempool over there.

I'll check, but I think they use an RCU?