From: Alexander Graf <graf@amazon.com>
To: Vishal Annapurve <vannapurve@google.com>,
"Kirill A. Shutemov" <kirill@shutemov.name>
Cc: <x86@kernel.org>, <linux-kernel@vger.kernel.org>,
<pbonzini@redhat.com>, <rientjes@google.com>, <seanjc@google.com>,
<erdemaktas@google.com>, <ackerleytng@google.com>,
<jxgao@google.com>, <sagis@google.com>, <oupton@google.com>,
<peterx@redhat.com>, <vkuznets@redhat.com>, <dmatlack@google.com>,
<pgonda@google.com>, <michael.roth@amd.com>,
<thomas.lendacky@amd.com>, <dave.hansen@linux.intel.com>,
<linux-coco@lists.linux.dev>, <chao.p.peng@linux.intel.com>,
<isaku.yamahata@gmail.com>, <andrew.jones@linux.dev>,
<corbet@lwn.net>, <hch@lst.de>, <m.szyprowski@samsung.com>,
<rostedt@goodmis.org>, <iommu@lists.linux.dev>
Subject: Re: [RFC V1 1/5] swiotlb: Support allocating DMA memory from SWIOTLB
Date: Thu, 15 Feb 2024 10:44:13 +0100 [thread overview]
Message-ID: <8a6dabdf-dc11-4989-b6b4-b49871ff9ca6@amazon.com> (raw)
In-Reply-To: <CAGtprH-95FEUzpc-yxQMo87gpqgMxyz9W8tiWtu_ZHhMW-jjuA@mail.gmail.com>
On 15.02.24 04:33, Vishal Annapurve wrote:
> On Wed, Feb 14, 2024 at 8:20 PM Kirill A. Shutemov <kirill@shutemov.name> wrote:
>> On Fri, Jan 12, 2024 at 05:52:47AM +0000, Vishal Annapurve wrote:
>>> Modify SWIOTLB framework to allocate DMA memory always from SWIOTLB.
>>>
>>> CVMs use SWIOTLB buffers for bouncing memory when using dma_map_* APIs
>>> to setup memory for IO operations. SWIOTLB buffers are marked as shared
>>> once during early boot.
>>>
>>> Buffers allocated using dma_alloc_* APIs are allocated from kernel memory
>>> and then converted to shared during each API invocation. This patch ensures
>>> that such buffers are also allocated from already shared SWIOTLB
>>> regions. This allows enforcing alignment requirements on regions marked
>>> as shared.
>> But does it work in practice?
>>
>> Some devices (like GPUs) require a lot of DMA memory. So with this approach
>> we would need to have huge SWIOTLB buffer that is unused in most VMs.
>>
> Current implementation limits the size of statically allocated SWIOTLB
> memory pool to 1G. I was proposing to enable dynamic SWIOTLB for CVMs
> in addition to aligning the memory allocations to hugepage sizes, so
> that the SWIOTLB pool can be scaled up on demand.
>
> The issue with aligning the pool areas to hugepages is that hugepage
> allocation at runtime is not guaranteed. Guaranteeing the hugepage
> allocation might need calculating the upper bound in advance, which
> defeats the purpose of enabling dynamic SWIOTLB. I am open to
> suggestions here.
You could allocate a max bound at boot using CMA and then only fill into
the CMA area when SWIOTLB size requirements increase? The CMA region
will allow movable allocations as long as you don't require the CMA space.
Alex
Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879
next prev parent reply other threads:[~2024-02-15 9:44 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-12 5:52 [RFC V1 0/5] x86: CVMs: Align memory conversions to 2M granularity Vishal Annapurve
2024-01-12 5:52 ` [RFC V1 1/5] swiotlb: Support allocating DMA memory from SWIOTLB Vishal Annapurve
2024-02-14 14:49 ` Kirill A. Shutemov
2024-02-15 3:33 ` Vishal Annapurve
2024-02-15 9:44 ` Alexander Graf [this message]
2024-02-15 20:26 ` Michael Kelley
2024-02-24 17:07 ` Vishal Annapurve
2024-02-24 22:02 ` Michael Kelley
2024-03-05 17:19 ` Vishal Annapurve
2024-01-12 5:52 ` [RFC V1 2/5] swiotlb: Allow setting up default alignment of SWIOTLB region Vishal Annapurve
2024-01-12 5:52 ` [RFC V1 3/5] x86: CVMs: Enable dynamic swiotlb by default for CVMs Vishal Annapurve
2024-02-01 12:20 ` Jeremi Piotrowski
2024-02-02 4:40 ` Vishal Annapurve
2024-01-12 5:52 ` [RFC V1 4/5] x86: CVMs: Allow allocating all DMA memory from SWIOTLB Vishal Annapurve
2024-01-31 16:17 ` Dave Hansen
2024-02-01 3:41 ` Vishal Annapurve
2024-01-12 5:52 ` [RFC V1 5/5] x86: CVMs: Ensure that memory conversions happen at 2M alignment Vishal Annapurve
2024-01-31 16:33 ` Dave Hansen
2024-02-01 3:46 ` Vishal Annapurve
2024-02-01 12:02 ` Jeremi Piotrowski
2024-02-02 5:08 ` Vishal Annapurve
2024-02-02 8:00 ` Jeremi Piotrowski
2024-02-02 16:22 ` Vishal Annapurve
2024-02-02 16:35 ` Dave Hansen
2024-02-03 5:19 ` Vishal Annapurve
2024-01-30 16:42 ` [RFC V1 0/5] x86: CVMs: Align memory conversions to 2M granularity Vishal Annapurve
2024-01-31 16:52 ` Dave Hansen
2024-02-01 5:44 ` Vishal Annapurve
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=8a6dabdf-dc11-4989-b6b4-b49871ff9ca6@amazon.com \
--to=graf@amazon.com \
--cc=ackerleytng@google.com \
--cc=andrew.jones@linux.dev \
--cc=chao.p.peng@linux.intel.com \
--cc=corbet@lwn.net \
--cc=dave.hansen@linux.intel.com \
--cc=dmatlack@google.com \
--cc=erdemaktas@google.com \
--cc=hch@lst.de \
--cc=iommu@lists.linux.dev \
--cc=isaku.yamahata@gmail.com \
--cc=jxgao@google.com \
--cc=kirill@shutemov.name \
--cc=linux-coco@lists.linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=m.szyprowski@samsung.com \
--cc=michael.roth@amd.com \
--cc=oupton@google.com \
--cc=pbonzini@redhat.com \
--cc=peterx@redhat.com \
--cc=pgonda@google.com \
--cc=rientjes@google.com \
--cc=rostedt@goodmis.org \
--cc=sagis@google.com \
--cc=seanjc@google.com \
--cc=thomas.lendacky@amd.com \
--cc=vannapurve@google.com \
--cc=vkuznets@redhat.com \
--cc=x86@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