From: Jerome Glisse <jglisse@redhat.com>
To: Randy Dunlap <rdunlap@infradead.org>
Cc: akpm@linux-foundation.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org,
Linus Torvalds <torvalds@linux-foundation.org>,
joro@8bytes.org, Mel Gorman <mgorman@suse.de>,
"H. Peter Anvin" <hpa@zytor.com>,
Peter Zijlstra <peterz@infradead.org>,
Andrea Arcangeli <aarcange@redhat.com>,
Johannes Weiner <jweiner@redhat.com>,
Larry Woodman <lwoodman@redhat.com>,
Rik van Riel <riel@redhat.com>, Dave Airlie <airlied@redhat.com>,
Brendan Conoboy <blc@redhat.com>,
Joe Donohue <jdonohue@redhat.com>,
Christophe Harle <charle@nvidia.com>,
Duncan Poole <dpoole@nvidia.com>,
Sherry Cheung <SCheung@nvidia.com>,
Subhash Gutti <sgutti@nvidia.com>,
John Hubbard <jhubbard@nvidia.com>,
Mark Hairgrove <mhairgrove@nvidia.com>,
Lucien Dunning <ldunning@nvidia.com>,
Cameron Buschardt <cabuschardt@nvidia.com>,
Arvind Gopalakrishnan <arvindg@nvidia.com>,
Haggai Eran <haggaie@mellanox.com>,
Shachar Raindel <raindel@mellanox.com>,
Liran Liss <liranl@mellanox.com>,
Roland Dreier <roland@purestorage.com>,
Ben Sander <ben.sander@amd.com>,
Greg Stoner <Greg.Stoner@amd.com>,
John Bridgman <John.Bridgman@amd.com>,
Michael Mantor <Michael.Mantor@amd.com>,
Paul Blinzer <Paul.Blinzer@amd.com>,
Leonid Shamis <Leonid.Shamis@amd.com>,
Laurent Morichetti <Laurent.Morichetti@amd.com>,
Alexander Deucher <Alexander.Deucher@amd.com>
Subject: Re: [PATCH v11 15/15] HMM: add documentation explaining HMM internals and how to use it.
Date: Thu, 22 Oct 2015 10:11:11 -0400 [thread overview]
Message-ID: <20151022141111.GA2914@redhat.com> (raw)
In-Reply-To: <562856BD.3020806@infradead.org>
On Wed, Oct 21, 2015 at 08:23:41PM -0700, Randy Dunlap wrote:
> Hi,
>
> Some corrections and a few questions...
Thanks for the corrections. Answer below.
> On 10/21/15 14:00, JA(C)rA'me Glisse wrote:
> > This add documentation on how HMM works and a more in depth view of how it
> > should be use by device driver writers.
> >
> > Signed-off-by: JA(C)rA'me Glisse <jglisse@redhat.com>
[...]
> > +synchronizing device page table for range that the device driver explicitly ask
>
> ranges asks
>
> or is only one range supported?
Several ranges are supported.
[...]
> > + /* Mirror memory (in read mode) between addressA and addressB */
> > + your_hmm_event->hmm_event.start = addressA;
> > + your_hmm_event->hmm_event.end = addressB;
>
> Multiple events (ranges) can be specified?
Device driver have to make one call per range but multiple threads can make
concurrent call for different ranges.
> Is hmm_event.end (addressB) included or excluded from the range?
Forgot to copy comment from header file, start is inclusive, end is exclusive.
[...]
> > + struct hmm_pt_iter iter;
> > + hmm_pt_iter_init(&iter, &mirror->pt)
> > +
> > + /* Get pointer to HMM page table entry for a given address. */
> > + dma_addr_t *hmm_pte;
> > + hmm_pte = hmm_pt_iter_walk(&iter, &addr, &next);
>
> what are 'addr' and 'next'? (types)
unsigned long will add then to the doc, good point.
[...]
> > + /* Migrate system memory between addressA and addressB to device memory. */
> > + your_hmm_event->hmm_event.start = addressA;
> > + your_hmm_event->hmm_event.end = addressB;
>
> is hmm_event.end (addressB) inclusive and exclusive?
> i.e., is it end_of_copy + 1?
> i.e., is the size of the copy addressB - addressA or
> addressB - addressA + 1?
> i.e., is addressB = addressA + size
> or is addressB = addressA + size - 1
Exclusive last one.
> In my experience it is usually better to have a start_address and size
> instead of start_address and end_address.
I switched several time btw the 2 offer differents version of the patchset,
it is something that can be change down the road unless you have strong
feeling about it.
Cheers,
Jerome
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Jerome Glisse <jglisse@redhat.com>
To: Randy Dunlap <rdunlap@infradead.org>
Cc: akpm@linux-foundation.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org,
Linus Torvalds <torvalds@linux-foundation.org>,
joro@8bytes.org, Mel Gorman <mgorman@suse.de>,
"H. Peter Anvin" <hpa@zytor.com>,
Peter Zijlstra <peterz@infradead.org>,
Andrea Arcangeli <aarcange@redhat.com>,
Johannes Weiner <jweiner@redhat.com>,
Larry Woodman <lwoodman@redhat.com>,
Rik van Riel <riel@redhat.com>, Dave Airlie <airlied@redhat.com>,
Brendan Conoboy <blc@redhat.com>,
Joe Donohue <jdonohue@redhat.com>,
Christophe Harle <charle@nvidia.com>,
Duncan Poole <dpoole@nvidia.com>,
Sherry Cheung <SCheung@nvidia.com>,
Subhash Gutti <sgutti@nvidia.com>,
John Hubbard <jhubbard@nvidia.com>,
Mark Hairgrove <mhairgrove@nvidia.com>,
Lucien Dunning <ldunning@nvidia.com>,
Cameron Buschardt <cabuschardt@nvidia.com>,
Arvind Gopalakrishnan <arvindg@nvidia.com>,
Haggai Eran <haggaie@mellanox.com>,
Shachar Raindel <raindel@mellanox.com>,
Liran Liss <liranl@mellanox.com>,
Roland Dreier <roland@purestorage.com>,
Ben Sander <ben.sander@amd.com>,
Greg Stoner <Greg.Stoner@amd.com>,
John Bridgman <John.Bridgman@amd.com>,
Michael Mantor <Michael.Mantor@amd.com>,
Paul Blinzer <Paul.Blinzer@amd.com>,
Leonid Shamis <Leonid.Shamis@amd.com>,
Laurent Morichetti <Laurent.Morichetti@amd.com>,
Alexander Deucher <Alexander.Deucher@amd.com>
Subject: Re: [PATCH v11 15/15] HMM: add documentation explaining HMM internals and how to use it.
Date: Thu, 22 Oct 2015 10:11:11 -0400 [thread overview]
Message-ID: <20151022141111.GA2914@redhat.com> (raw)
In-Reply-To: <562856BD.3020806@infradead.org>
On Wed, Oct 21, 2015 at 08:23:41PM -0700, Randy Dunlap wrote:
> Hi,
>
> Some corrections and a few questions...
Thanks for the corrections. Answer below.
> On 10/21/15 14:00, Jérôme Glisse wrote:
> > This add documentation on how HMM works and a more in depth view of how it
> > should be use by device driver writers.
> >
> > Signed-off-by: Jérôme Glisse <jglisse@redhat.com>
[...]
> > +synchronizing device page table for range that the device driver explicitly ask
>
> ranges asks
>
> or is only one range supported?
Several ranges are supported.
[...]
> > + /* Mirror memory (in read mode) between addressA and addressB */
> > + your_hmm_event->hmm_event.start = addressA;
> > + your_hmm_event->hmm_event.end = addressB;
>
> Multiple events (ranges) can be specified?
Device driver have to make one call per range but multiple threads can make
concurrent call for different ranges.
> Is hmm_event.end (addressB) included or excluded from the range?
Forgot to copy comment from header file, start is inclusive, end is exclusive.
[...]
> > + struct hmm_pt_iter iter;
> > + hmm_pt_iter_init(&iter, &mirror->pt)
> > +
> > + /* Get pointer to HMM page table entry for a given address. */
> > + dma_addr_t *hmm_pte;
> > + hmm_pte = hmm_pt_iter_walk(&iter, &addr, &next);
>
> what are 'addr' and 'next'? (types)
unsigned long will add then to the doc, good point.
[...]
> > + /* Migrate system memory between addressA and addressB to device memory. */
> > + your_hmm_event->hmm_event.start = addressA;
> > + your_hmm_event->hmm_event.end = addressB;
>
> is hmm_event.end (addressB) inclusive and exclusive?
> i.e., is it end_of_copy + 1?
> i.e., is the size of the copy addressB - addressA or
> addressB - addressA + 1?
> i.e., is addressB = addressA + size
> or is addressB = addressA + size - 1
Exclusive last one.
> In my experience it is usually better to have a start_address and size
> instead of start_address and end_address.
I switched several time btw the 2 offer differents version of the patchset,
it is something that can be change down the road unless you have strong
feeling about it.
Cheers,
Jérôme
next prev parent reply other threads:[~2015-10-22 14:11 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-21 20:59 [PATCH v11 00/15] HMM (Heterogeneous Memory Management) Jérôme Glisse
2015-10-21 20:59 ` Jérôme Glisse
2015-10-21 20:59 ` [PATCH v11 01/15] mmu_notifier: add event information to address invalidation v8 Jérôme Glisse
2015-10-21 20:59 ` Jérôme Glisse
2015-10-21 20:59 ` [PATCH v11 02/15] mmu_notifier: keep track of active invalidation ranges v5 Jérôme Glisse
2015-10-21 20:59 ` Jérôme Glisse
2015-10-21 20:59 ` [PATCH v11 03/15] mmu_notifier: pass page pointer to mmu_notifier_invalidate_page() v2 Jérôme Glisse
2015-10-21 20:59 ` Jérôme Glisse
2015-10-21 20:59 ` [PATCH v11 04/15] mmu_notifier: allow range invalidation to exclude a specific mmu_notifier Jérôme Glisse
2015-10-21 20:59 ` Jérôme Glisse
2015-10-21 21:00 ` [PATCH v11 05/15] HMM: introduce heterogeneous memory management v5 Jérôme Glisse
2015-10-21 21:00 ` Jérôme Glisse
2015-10-21 20:18 ` Randy Dunlap
2015-10-21 20:18 ` Randy Dunlap
2015-10-21 21:00 ` [PATCH v11 06/15] HMM: add HMM page table v4 Jérôme Glisse
2015-10-21 21:00 ` Jérôme Glisse
2015-10-21 21:00 ` [PATCH v11 07/15] HMM: add per mirror " Jérôme Glisse
2015-10-21 21:00 ` Jérôme Glisse
2015-10-21 21:00 ` [PATCH v11 08/15] HMM: add device page fault support v6 Jérôme Glisse
2015-10-21 21:00 ` Jérôme Glisse
2015-10-21 21:00 ` [PATCH v11 09/15] HMM: add mm page table iterator helpers Jérôme Glisse
2015-10-21 21:00 ` Jérôme Glisse
2015-10-21 21:00 ` [PATCH v11 10/15] HMM: use CPU page table during invalidation Jérôme Glisse
2015-10-21 21:00 ` Jérôme Glisse
2015-10-21 21:00 ` [PATCH v11 11/15] HMM: add discard range helper (to clear and free resources for a range) Jérôme Glisse
2015-10-21 21:00 ` Jérôme Glisse
2015-10-21 21:00 ` [PATCH v11 12/15] HMM: add dirty range helper (toggle dirty bit inside mirror page table) v2 Jérôme Glisse
2015-10-21 21:00 ` Jérôme Glisse
2015-10-21 21:00 ` [PATCH v11 13/15] HMM: DMA map memory on behalf of device driver v2 Jérôme Glisse
2015-10-21 21:00 ` Jérôme Glisse
2015-10-21 21:00 ` [PATCH v11 14/15] HMM: Add support for hugetlb Jérôme Glisse
2015-10-21 21:00 ` Jérôme Glisse
2015-10-21 21:00 ` [PATCH v11 15/15] HMM: add documentation explaining HMM internals and how to use it Jérôme Glisse
2015-10-21 21:00 ` Jérôme Glisse
2015-10-22 3:23 ` Randy Dunlap
2015-10-22 3:23 ` Randy Dunlap
2015-10-22 14:11 ` Jerome Glisse [this message]
2015-10-22 14:11 ` Jerome Glisse
2015-10-28 1:19 ` David Woodhouse
2015-10-28 17:10 ` Randy Dunlap
2015-10-28 17:10 ` Randy Dunlap
2015-10-25 10:00 ` [PATCH v11 00/15] HMM (Heterogeneous Memory Management) Haggai Eran
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=20151022141111.GA2914@redhat.com \
--to=jglisse@redhat.com \
--cc=Alexander.Deucher@amd.com \
--cc=Greg.Stoner@amd.com \
--cc=John.Bridgman@amd.com \
--cc=Laurent.Morichetti@amd.com \
--cc=Leonid.Shamis@amd.com \
--cc=Michael.Mantor@amd.com \
--cc=Paul.Blinzer@amd.com \
--cc=SCheung@nvidia.com \
--cc=aarcange@redhat.com \
--cc=airlied@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=arvindg@nvidia.com \
--cc=ben.sander@amd.com \
--cc=blc@redhat.com \
--cc=cabuschardt@nvidia.com \
--cc=charle@nvidia.com \
--cc=dpoole@nvidia.com \
--cc=haggaie@mellanox.com \
--cc=hpa@zytor.com \
--cc=jdonohue@redhat.com \
--cc=jhubbard@nvidia.com \
--cc=joro@8bytes.org \
--cc=jweiner@redhat.com \
--cc=ldunning@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=liranl@mellanox.com \
--cc=lwoodman@redhat.com \
--cc=mgorman@suse.de \
--cc=mhairgrove@nvidia.com \
--cc=peterz@infradead.org \
--cc=raindel@mellanox.com \
--cc=rdunlap@infradead.org \
--cc=riel@redhat.com \
--cc=roland@purestorage.com \
--cc=sgutti@nvidia.com \
--cc=torvalds@linux-foundation.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 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.