>> >
>> > Given that, an alternative proposal that I think would work
>> > for you would be to add a 'placeholder' memory node definition
>> > in SRAT (so allow 0 size explicitly - might need a new SRAT
>> > entry to avoid backwards compat issues).
>>
>> Putting all the PCI/GI/... complexity aside,
On Wed, Jan 10, 2024 at 03:19:05PM -0800, Dan Williams wrote:
> David Hildenbrand wrote:
> > On 09.01.24 17:52, Jonathan Cameron wrote:
> > > On Thu, 4 Jan 2024 10:39:41 -0700
> > > Alex Williamson wrote:
> > >
> > >> On Thu, 4 Jan 2024 16:40:39 +
> > >> Ankit Agrawal wrote:
> > >>
> > >>> H
On Tue, Jan 09, 2024 at 11:36:03AM -0800, Dan Williams wrote:
> Jason Gunthorpe wrote:
> > On Tue, Jan 09, 2024 at 06:02:03PM +0100, David Hildenbrand wrote:
> > > > Given that, an alternative proposal that I think would work
> > > > for you would be to add a 'placeholder' memory node definition
>
Jason Gunthorpe wrote:
> On Tue, Jan 09, 2024 at 06:02:03PM +0100, David Hildenbrand wrote:
> > > Given that, an alternative proposal that I think would work
> > > for you would be to add a 'placeholder' memory node definition
> > > in SRAT (so allow 0 size explicitly - might need a new SRAT
> > >
On Tue, Jan 09, 2024 at 06:02:03PM +0100, David Hildenbrand wrote:
> > Given that, an alternative proposal that I think would work
> > for you would be to add a 'placeholder' memory node definition
> > in SRAT (so allow 0 size explicitly - might need a new SRAT
> > entry to avoid backwards compat i
On 09.01.24 17:52, Jonathan Cameron wrote:
On Thu, 4 Jan 2024 10:39:41 -0700
Alex Williamson wrote:
On Thu, 4 Jan 2024 16:40:39 +
Ankit Agrawal wrote:
Had a discussion with RH folks, summary follows:
1. To align with the current spec description pointed by Jonathan, we first do
a
On Thu, 4 Jan 2024 10:39:41 -0700
Alex Williamson wrote:
> On Thu, 4 Jan 2024 16:40:39 +
> Ankit Agrawal wrote:
>
> > Had a discussion with RH folks, summary follows:
> >
> > 1. To align with the current spec description pointed by Jonathan, we first
> > do
> > a separate object inst
On Thu, 4 Jan 2024 03:36:06 +
Ankit Agrawal wrote:
> Thanks Jonathan for the review.
>
> > As per reply to the cover letter I definitely want to see SRAT table dumps
> > in here though so we can easily see what this is actually building.
>
> Ack.
>
> > I worry that some OS might make the
Ankit Agrawal writes:
>>> +##
>>> +# @AcpiGenericInitiatorProperties:
>>> +#
>>> +# Properties for acpi-generic-initiator objects.
>>> +#
>>> +# @pci-dev: PCI device ID to be associated with the node
>>> +#
>>> +# @host-nodes: numa node list associated with the PCI device.
>>
>> NUMA
>>
>> Sugges
>> > However, I'll leave it up to those more familiar with the QEMU numa
>> > control interface design to comment on whether this approach is preferable
>> > to making the gi part of the numa node entry or doing it like hmat.
>>
>> > -numa srat-gi,node-id=10,gi-pci-dev=dev1
>>
>> The current way o
>> +##
>> +# @AcpiGenericInitiatorProperties:
>> +#
>> +# Properties for acpi-generic-initiator objects.
>> +#
>> +# @pci-dev: PCI device ID to be associated with the node
>> +#
>> +# @host-nodes: numa node list associated with the PCI device.
>
> NUMA
>
> Suggest "list of NUMA nodes associated wi
writes:
> From: Ankit Agrawal
>
> NVIDIA GPU's support MIG (Mult-Instance GPUs) feature [1], which allows
> partitioning of the GPU device resources (including device memory) into
> several (upto 8) isolated instances. Each of the partitioned memory needs
> a dedicated NUMA node to operate. The
On Thu, 4 Jan 2024 16:40:39 +
Ankit Agrawal wrote:
> Had a discussion with RH folks, summary follows:
>
> 1. To align with the current spec description pointed by Jonathan, we first do
> a separate object instance per GI node as suggested by Jonathan. i.e.
> a acpi-generic-initiato
On Thu, 4 Jan 2024 03:36:06 +
Ankit Agrawal wrote:
> Thanks Jonathan for the review.
>
> > As per reply to the cover letter I definitely want to see SRAT table dumps
> > in here though so we can easily see what this is actually building.
>
> Ack.
>
> > I worry that some OS might make the
Had a discussion with RH folks, summary follows:
1. To align with the current spec description pointed by Jonathan, we first do
a separate object instance per GI node as suggested by Jonathan. i.e.
a acpi-generic-initiator would only link one node to the device. To
associate a set
>> However, I'll leave it up to those more familiar with the QEMU numa
>> control interface design to comment on whether this approach is preferable
>> to making the gi part of the numa node entry or doing it like hmat.
>> -numa srat-gi,node-id=10,gi-pci-dev=dev1
>
> The current way of acpi-generic
Thanks Jonathan for the review.
> As per reply to the cover letter I definitely want to see SRAT table dumps
> in here though so we can easily see what this is actually building.
Ack.
> I worry that some OS might make the assumption that it's one GI node
> per PCI device though. The language in
On Mon, 25 Dec 2023 10:26:02 +0530
wrote:
> From: Ankit Agrawal
>
> NVIDIA GPU's support MIG (Mult-Instance GPUs) feature [1], which allows
> partitioning of the GPU device resources (including device memory) into
> several (upto 8) isolated instances. Each of the partitioned memory needs
> a d
From: Ankit Agrawal
NVIDIA GPU's support MIG (Mult-Instance GPUs) feature [1], which allows
partitioning of the GPU device resources (including device memory) into
several (upto 8) isolated instances. Each of the partitioned memory needs
a dedicated NUMA node to operate. The partitions are not fi
19 matches
Mail list logo
