From: Jason Gunthorpe <jgg@nvidia.com>
To: "Sierra Guiza, Alejandro (Alex)" <alex.sierra@amd.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 14:26:48 -0300 [thread overview]
Message-ID: <20210722172648.GN1117491@nvidia.com> (raw)
In-Reply-To: <4ee9e946-d380-ba84-d6ac-5ad337afc835@amd.com>
On Thu, Jul 22, 2021 at 11:59:17AM -0500, Sierra Guiza, Alejandro (Alex) wrote:
>
> 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().
I don't think anything about hmm is sensitive to how the pages are
acquired - you can't create device generic pages without relying on
FAKE_MEMMAP?
Jason
WARNING: multiple messages have this Message-ID (diff)
From: Jason Gunthorpe <jgg@nvidia.com>
To: "Sierra Guiza, Alejandro (Alex)" <alex.sierra@amd.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 14:26:48 -0300 [thread overview]
Message-ID: <20210722172648.GN1117491@nvidia.com> (raw)
In-Reply-To: <4ee9e946-d380-ba84-d6ac-5ad337afc835@amd.com>
On Thu, Jul 22, 2021 at 11:59:17AM -0500, Sierra Guiza, Alejandro (Alex) wrote:
>
> 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().
I don't think anything about hmm is sensitive to how the pages are
acquired - you can't create device generic pages without relying on
FAKE_MEMMAP?
Jason
WARNING: multiple messages have this Message-ID (diff)
From: Jason Gunthorpe <jgg@nvidia.com>
To: "Sierra Guiza, Alejandro (Alex)" <alex.sierra@amd.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 14:26:48 -0300 [thread overview]
Message-ID: <20210722172648.GN1117491@nvidia.com> (raw)
In-Reply-To: <4ee9e946-d380-ba84-d6ac-5ad337afc835@amd.com>
On Thu, Jul 22, 2021 at 11:59:17AM -0500, Sierra Guiza, Alejandro (Alex) wrote:
>
> 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().
I don't think anything about hmm is sensitive to how the pages are
acquired - you can't create device generic pages without relying on
FAKE_MEMMAP?
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 17:26 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)
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 [this message]
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=20210722172648.GN1117491@nvidia.com \
--to=jgg@nvidia.com \
--cc=Felix.Kuehling@amd.com \
--cc=akpm@linux-foundation.org \
--cc=alex.sierra@amd.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=hch@lst.de \
--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.