From: "Sierra Guiza, Alejandro (Alex)" <alex.sierra@amd.com>
To: Jason Gunthorpe <jgg@nvidia.com>
Cc: rcampbell@nvidia.com, Felix.Kuehling@amd.com,
amd-gfx@lists.freedesktop.org, linux-xfs@vger.kernel.org,
linux-mm@kvack.org, jglisse@redhat.com,
dri-devel@lists.freedesktop.org, akpm@linux-foundation.org,
linux-ext4@vger.kernel.org, hch@lst.de
Subject: Re: [PATCH v4 10/13] lib: test_hmm add module param for zone device type
Date: Thu, 22 Jul 2021 11:59:17 -0500 [thread overview]
Message-ID: <4ee9e946-d380-ba84-d6ac-5ad337afc835@amd.com> (raw)
In-Reply-To: <20210722122348.GG1117491@nvidia.com>
On 7/22/2021 7:23 AM, Jason Gunthorpe wrote:
> On Sat, Jul 17, 2021 at 02:21:32PM -0500, Alex Sierra wrote:
>> In order to configure device generic in test_hmm, two
>> module parameters should be passed, which correspon to the
>> SP start address of each device (2) spm_addr_dev0 &
>> spm_addr_dev1. If no parameters are passed, private device
>> type is configured.
> I don't think tests should need configuration like this, is it really
> necessary? How can people with normal HW run this test?
Hi Jason,
The idea was to add an easy way to validate the codepaths touched by this
patch series, which make modifications to the migration helpers for device
generic type pages. We're using CONFIG_EFI_FAKE_MEMMAP to create fake SPM
devices inside system memory. No special HW needed. And passing the kernel
parameter efi_fake_mem. Ex. efi_fake_mem=1G@0x100000000:0x40000. I should
probably need to include a small example of how to set this in the
test_hmm.sh
usage().
Alex S.
> Jason
WARNING: multiple messages have this Message-ID (diff)
From: "Sierra Guiza, Alejandro (Alex)" <alex.sierra@amd.com>
To: Jason Gunthorpe <jgg@nvidia.com>
Cc: akpm@linux-foundation.org, Felix.Kuehling@amd.com,
linux-mm@kvack.org, rcampbell@nvidia.com,
linux-ext4@vger.kernel.org, linux-xfs@vger.kernel.org,
amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
hch@lst.de, jglisse@redhat.com
Subject: Re: [PATCH v4 10/13] lib: test_hmm add module param for zone device type
Date: Thu, 22 Jul 2021 11:59:17 -0500 [thread overview]
Message-ID: <4ee9e946-d380-ba84-d6ac-5ad337afc835@amd.com> (raw)
In-Reply-To: <20210722122348.GG1117491@nvidia.com>
On 7/22/2021 7:23 AM, Jason Gunthorpe wrote:
> On Sat, Jul 17, 2021 at 02:21:32PM -0500, Alex Sierra wrote:
>> In order to configure device generic in test_hmm, two
>> module parameters should be passed, which correspon to the
>> SP start address of each device (2) spm_addr_dev0 &
>> spm_addr_dev1. If no parameters are passed, private device
>> type is configured.
> I don't think tests should need configuration like this, is it really
> necessary? How can people with normal HW run this test?
Hi Jason,
The idea was to add an easy way to validate the codepaths touched by this
patch series, which make modifications to the migration helpers for device
generic type pages. We're using CONFIG_EFI_FAKE_MEMMAP to create fake SPM
devices inside system memory. No special HW needed. And passing the kernel
parameter efi_fake_mem. Ex. efi_fake_mem=1G@0x100000000:0x40000. I should
probably need to include a small example of how to set this in the
test_hmm.sh
usage().
Alex S.
> Jason
WARNING: multiple messages have this Message-ID (diff)
From: "Sierra Guiza, Alejandro (Alex)" <alex.sierra@amd.com>
To: Jason Gunthorpe <jgg@nvidia.com>
Cc: rcampbell@nvidia.com, Felix.Kuehling@amd.com,
amd-gfx@lists.freedesktop.org, linux-xfs@vger.kernel.org,
linux-mm@kvack.org, jglisse@redhat.com,
dri-devel@lists.freedesktop.org, akpm@linux-foundation.org,
linux-ext4@vger.kernel.org, hch@lst.de
Subject: Re: [PATCH v4 10/13] lib: test_hmm add module param for zone device type
Date: Thu, 22 Jul 2021 11:59:17 -0500 [thread overview]
Message-ID: <4ee9e946-d380-ba84-d6ac-5ad337afc835@amd.com> (raw)
In-Reply-To: <20210722122348.GG1117491@nvidia.com>
On 7/22/2021 7:23 AM, Jason Gunthorpe wrote:
> On Sat, Jul 17, 2021 at 02:21:32PM -0500, Alex Sierra wrote:
>> In order to configure device generic in test_hmm, two
>> module parameters should be passed, which correspon to the
>> SP start address of each device (2) spm_addr_dev0 &
>> spm_addr_dev1. If no parameters are passed, private device
>> type is configured.
> I don't think tests should need configuration like this, is it really
> necessary? How can people with normal HW run this test?
Hi Jason,
The idea was to add an easy way to validate the codepaths touched by this
patch series, which make modifications to the migration helpers for device
generic type pages. We're using CONFIG_EFI_FAKE_MEMMAP to create fake SPM
devices inside system memory. No special HW needed. And passing the kernel
parameter efi_fake_mem. Ex. efi_fake_mem=1G@0x100000000:0x40000. I should
probably need to include a small example of how to set this in the
test_hmm.sh
usage().
Alex S.
> Jason
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
next prev parent reply other threads:[~2021-07-22 16:59 UTC|newest]
Thread overview: 64+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-17 19:21 [PATCH v4 00/13] Support DEVICE_GENERIC memory in migrate_vma_* Alex Sierra
2021-07-17 19:21 ` Alex Sierra
2021-07-17 19:21 ` Alex Sierra
2021-07-17 19:21 ` [PATCH v4 01/13] ext4/xfs: add page refcount helper Alex Sierra
2021-07-17 19:21 ` Alex Sierra
2021-07-17 19:21 ` Alex Sierra
2021-07-17 19:21 ` [PATCH v4 02/13] mm: remove extra ZONE_DEVICE struct page refcount Alex Sierra
2021-07-17 19:21 ` Alex Sierra
2021-07-17 19:21 ` Alex Sierra
2021-07-17 19:21 ` [PATCH v4 03/13] kernel: resource: lookup_resource as exported symbol Alex Sierra
2021-07-17 19:21 ` Alex Sierra
2021-07-17 19:21 ` Alex Sierra
2021-07-19 9:16 ` Christoph Hellwig
2021-07-19 9:16 ` Christoph Hellwig
2021-07-17 19:21 ` [PATCH v4 04/13] drm/amdkfd: add SPM support for SVM Alex Sierra
2021-07-17 19:21 ` Alex Sierra
2021-07-17 19:21 ` Alex Sierra
2021-07-17 19:21 ` [PATCH v4 05/13] drm/amdkfd: generic type as sys mem on migration to ram Alex Sierra
2021-07-17 19:21 ` Alex Sierra
2021-07-17 19:21 ` Alex Sierra
2021-07-19 9:17 ` Christoph Hellwig
2021-07-19 9:17 ` Christoph Hellwig
2021-07-17 19:21 ` [PATCH v4 06/13] include/linux/mm.h: helpers to check zone device generic type Alex Sierra
2021-07-17 19:21 ` Alex Sierra
2021-07-17 19:21 ` Alex Sierra
2021-07-19 20:47 ` Zeng, Oak
2021-07-19 20:47 ` Zeng, Oak
2021-07-19 20:47 ` Zeng, Oak
2021-07-17 19:21 ` [PATCH v4 07/13] mm: add generic type support to migrate_vma helpers Alex Sierra
2021-07-17 19:21 ` Alex Sierra
2021-07-17 19:21 ` Alex Sierra
2021-07-17 19:21 ` [PATCH v4 08/13] mm: call pgmap->ops->page_free for DEVICE_GENERIC pages Alex Sierra
2021-07-17 19:21 ` Alex Sierra
2021-07-17 19:21 ` Alex Sierra
2021-07-19 9:18 ` Christoph Hellwig
2021-07-19 9:18 ` Christoph Hellwig
2021-07-17 19:21 ` [PATCH v4 09/13] lib: test_hmm add ioctl to get zone device type Alex Sierra
2021-07-17 19:21 ` Alex Sierra
2021-07-17 19:21 ` Alex Sierra
2021-07-17 19:21 ` [PATCH v4 10/13] lib: test_hmm add module param for " Alex Sierra
2021-07-17 19:21 ` Alex Sierra
2021-07-17 19:21 ` Alex Sierra
2021-07-22 12:23 ` Jason Gunthorpe
2021-07-22 12:23 ` Jason Gunthorpe
2021-07-22 12:23 ` Jason Gunthorpe
2021-07-22 16:59 ` Sierra Guiza, Alejandro (Alex) [this message]
2021-07-22 16:59 ` Sierra Guiza, Alejandro (Alex)
2021-07-22 16:59 ` Sierra Guiza, Alejandro (Alex)
2021-07-22 17:26 ` Jason Gunthorpe
2021-07-22 17:26 ` Jason Gunthorpe
2021-07-22 17:26 ` Jason Gunthorpe
2021-07-28 23:45 ` Sierra Guiza, Alejandro (Alex)
2021-07-28 23:45 ` Sierra Guiza, Alejandro (Alex)
2021-07-28 23:45 ` Sierra Guiza, Alejandro (Alex)
2021-07-30 19:11 ` Felix Kuehling
2021-07-17 19:21 ` [PATCH v4 11/13] lib: add support for device generic type in test_hmm Alex Sierra
2021-07-17 19:21 ` Alex Sierra
2021-07-17 19:21 ` Alex Sierra
2021-07-17 19:21 ` [PATCH v4 12/13] tools: update hmm-test to support device generic type Alex Sierra
2021-07-17 19:21 ` Alex Sierra
2021-07-17 19:21 ` Alex Sierra
2021-07-17 19:21 ` [PATCH v4 13/13] tools: update test_hmm script to support SP config Alex Sierra
2021-07-17 19:21 ` Alex Sierra
2021-07-17 19:21 ` Alex Sierra
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=4ee9e946-d380-ba84-d6ac-5ad337afc835@amd.com \
--to=alex.sierra@amd.com \
--cc=Felix.Kuehling@amd.com \
--cc=akpm@linux-foundation.org \
--cc=amd-gfx@lists.freedesktop.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=hch@lst.de \
--cc=jgg@nvidia.com \
--cc=jglisse@redhat.com \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-xfs@vger.kernel.org \
--cc=rcampbell@nvidia.com \
/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.