All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Oliver O'Halloran" <oohall@gmail.com>
To: Dan Williams <dan.j.williams@intel.com>
Cc: Balbir Singh <bsingharora@gmail.com>,
	linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
	Reza Arbab <arbab@linux.vnet.ibm.com>,
	"linux-nvdimm@lists.01.org" <linux-nvdimm@lists.01.org>
Subject: Re: ZONE_DEVICE and pmem API support for powerpc
Date: Wed, 12 Apr 2017 19:14:02 +1000	[thread overview]
Message-ID: <CAOSf1CEtUHeQspR9=sRKJQxxsH==_82L8AzUy10aUj=d=e0_kA@mail.gmail.com> (raw)
In-Reply-To: <CAPcyv4hKnP_pddKP8Ve6R0n6sXihPeLCw5seq06iHJ=Hc3yaQA@mail.gmail.com>

On Wed, Apr 12, 2017 at 4:22 AM, Dan Williams <dan.j.williams@intel.com> wrote:
> On Tue, Apr 11, 2017 at 10:42 AM, Oliver O'Halloran <oohall@gmail.com> wrote:
>> Hi all,
>>
>> This series adds support for ZONE_DEVICE and the pmem api on powerpc. Namely,
>> support for altmaps and the various bits and pieces required for DAX PMD faults.
>> The first two patches touch generic mm/ code, but otherwise this is fairly well
>> contained in arch/powerpc.
>>
>> If the nvdimm folks could sanity check this series I'd appreciate it.
>
> Quick feedback: I'm in the process of cleaning up and resubmitting my
> patch set to push the pmem api down into the driver directly.
>
>     https://lwn.net/Articles/713064/

That's been on my radar for a while and I was hoping it would be in
4.12. Moving operations into the driver makes a lot of sense from a
design perspective and it should make supporting some of the
contutto's eccentricities a bit easier.

> I'm also reworking memory hotplug to allow sub-section allocations
> which has collided with Michal Hocko's hotplug reworks. It will be
> good to have some more eyes on that work to understand the cross-arch
> implications.
>
>     https://lkml.org/lkml/2017/3/19/146

I'd been putting off looking at this since I figured it would clash
with the hotplug rework and HMM, but I'll see if I can get it working
on ppc.

>> Series is based on next-20170411, but it should apply elsewhere with minor
>> fixups to arch_{add|remove}_memory due to conflicts with HMM.  For those
>> interested in testing this, there is a driver and matching firmware that carves
>> out some system memory for use as an emulated Con Tutto memory card.
>>
>> Driver: https://github.com/oohal/linux/tree/contutto-next
>> Firmware: https://github.com/oohal/skiboot/tree/fake-contutto
>>
>> Edit core/init.c:686 to control the amount of memory borrowed for the emulated
>> device.  I'm keeping the driver out of tree for a until 4.13 since I plan on
>> reworking the firmware interface anyway and There's at least one showstopper
>> bug.
>
> Is this memory card I/O-cache coherent? I.e. existing dma mapping api
> can hand out mappings to it? Just trying to figure out if this the
> existing pmem-definition of ZONE_DEVICE or a new one.

As far as the rest of the system is concerned Con Tutto memory is
identical to normal system memory. All accesses to the card's memory
is mediated by a memory controller which participates in the memory
coherency protocol. That said, the link between the card and the
system is non-coherent so logic on the FPGA can access memory
incoherently. I'm primarily interested in using the card as a memory
platform so I haven't spent a lot of time thinking about the latter
use case, but a different concept of device memory might be required
there.

Oliver
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

WARNING: multiple messages have this Message-ID (diff)
From: "Oliver O'Halloran" <oohall@gmail.com>
To: Dan Williams <dan.j.williams@intel.com>
Cc: linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
	Balbir Singh <bsingharora@gmail.com>,
	Reza Arbab <arbab@linux.vnet.ibm.com>,
	"linux-nvdimm@lists.01.org" <linux-nvdimm@lists.01.org>
Subject: Re: ZONE_DEVICE and pmem API support for powerpc
Date: Wed, 12 Apr 2017 19:14:02 +1000	[thread overview]
Message-ID: <CAOSf1CEtUHeQspR9=sRKJQxxsH==_82L8AzUy10aUj=d=e0_kA@mail.gmail.com> (raw)
In-Reply-To: <CAPcyv4hKnP_pddKP8Ve6R0n6sXihPeLCw5seq06iHJ=Hc3yaQA@mail.gmail.com>

On Wed, Apr 12, 2017 at 4:22 AM, Dan Williams <dan.j.williams@intel.com> wrote:
> On Tue, Apr 11, 2017 at 10:42 AM, Oliver O'Halloran <oohall@gmail.com> wrote:
>> Hi all,
>>
>> This series adds support for ZONE_DEVICE and the pmem api on powerpc. Namely,
>> support for altmaps and the various bits and pieces required for DAX PMD faults.
>> The first two patches touch generic mm/ code, but otherwise this is fairly well
>> contained in arch/powerpc.
>>
>> If the nvdimm folks could sanity check this series I'd appreciate it.
>
> Quick feedback: I'm in the process of cleaning up and resubmitting my
> patch set to push the pmem api down into the driver directly.
>
>     https://lwn.net/Articles/713064/

That's been on my radar for a while and I was hoping it would be in
4.12. Moving operations into the driver makes a lot of sense from a
design perspective and it should make supporting some of the
contutto's eccentricities a bit easier.

> I'm also reworking memory hotplug to allow sub-section allocations
> which has collided with Michal Hocko's hotplug reworks. It will be
> good to have some more eyes on that work to understand the cross-arch
> implications.
>
>     https://lkml.org/lkml/2017/3/19/146

I'd been putting off looking at this since I figured it would clash
with the hotplug rework and HMM, but I'll see if I can get it working
on ppc.

>> Series is based on next-20170411, but it should apply elsewhere with minor
>> fixups to arch_{add|remove}_memory due to conflicts with HMM.  For those
>> interested in testing this, there is a driver and matching firmware that carves
>> out some system memory for use as an emulated Con Tutto memory card.
>>
>> Driver: https://github.com/oohal/linux/tree/contutto-next
>> Firmware: https://github.com/oohal/skiboot/tree/fake-contutto
>>
>> Edit core/init.c:686 to control the amount of memory borrowed for the emulated
>> device.  I'm keeping the driver out of tree for a until 4.13 since I plan on
>> reworking the firmware interface anyway and There's at least one showstopper
>> bug.
>
> Is this memory card I/O-cache coherent? I.e. existing dma mapping api
> can hand out mappings to it? Just trying to figure out if this the
> existing pmem-definition of ZONE_DEVICE or a new one.

As far as the rest of the system is concerned Con Tutto memory is
identical to normal system memory. All accesses to the card's memory
is mediated by a memory controller which participates in the memory
coherency protocol. That said, the link between the card and the
system is non-coherent so logic on the FPGA can access memory
incoherently. I'm primarily interested in using the card as a memory
platform so I haven't spent a lot of time thinking about the latter
use case, but a different concept of device memory might be required
there.

Oliver

  reply	other threads:[~2017-04-12  9:14 UTC|newest]

Thread overview: 65+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-11 17:42 ZONE_DEVICE and pmem API support for powerpc Oliver O'Halloran
2017-04-11 17:42 ` Oliver O'Halloran
2017-04-11 17:42 ` [PATCH 1/9] mm/huge_memory: Use zap_deposited_table() more Oliver O'Halloran
2017-04-11 17:42   ` Oliver O'Halloran
2017-04-11 17:42   ` Oliver O'Halloran
2017-04-12  5:44   ` Aneesh Kumar K.V
2017-04-12  5:44     ` Aneesh Kumar K.V
2017-04-18 21:35   ` David Rientjes
2017-04-18 21:35     ` David Rientjes
2017-04-11 17:42 ` [PATCH 2/9] mm/huge_memory: Deposit a pgtable for DAX PMD faults when required Oliver O'Halloran
2017-04-11 17:42   ` Oliver O'Halloran
2017-04-11 17:42   ` Oliver O'Halloran
2017-04-12  5:51   ` Aneesh Kumar K.V
2017-04-12  5:51     ` Aneesh Kumar K.V
2017-04-12  5:51     ` Aneesh Kumar K.V
2017-04-11 17:42 ` [PATCH 3/9] powerpc/mm: Add _PAGE_DEVMAP for ppc64 Oliver O'Halloran
2017-04-11 17:42   ` Oliver O'Halloran
2017-04-12  0:19   ` Stephen Rothwell
2017-04-12  0:19     ` Stephen Rothwell
2017-04-12  3:07     ` Aneesh Kumar K.V
2017-04-12  3:07       ` Aneesh Kumar K.V
2017-04-13  5:20   ` Aneesh Kumar K.V
2017-04-13  5:20     ` Aneesh Kumar K.V
2017-04-11 17:42 ` [PATCH 4/9] powerpc/mm: Reshuffle vmemmap_free() Oliver O'Halloran
2017-04-11 17:42   ` Oliver O'Halloran
2017-04-12  0:33   ` Stephen Rothwell
2017-04-12  0:33     ` Stephen Rothwell
2017-04-11 17:42 ` [PATCH 5/9] powerpc/vmemmap: Add altmap support Oliver O'Halloran
2017-04-11 17:42   ` Oliver O'Halloran
2017-04-12  0:24   ` Balbir Singh
2017-04-12  0:24     ` Balbir Singh
2017-04-11 17:42 ` [PATCH 6/9] powerpc, mm: Enable ZONE_DEVICE on powerpc Oliver O'Halloran
2017-04-11 17:42   ` Oliver O'Halloran
2017-04-12  0:25   ` Balbir Singh
2017-04-12  0:25     ` Balbir Singh
2017-04-12  0:43   ` Stephen Rothwell
2017-04-12  0:43     ` Stephen Rothwell
2017-04-12  2:03     ` Michael Ellerman
2017-04-12  2:03       ` Michael Ellerman
2017-04-11 17:42 ` [PATCH 7/9] powerpc/mm: Wire up ioremap_cache Oliver O'Halloran
2017-04-11 17:42   ` Oliver O'Halloran
2017-04-23 11:53   ` [7/9] " Michael Ellerman
2017-04-23 11:53     ` Michael Ellerman
2017-04-11 17:42 ` [PATCH 8/9] powerpc/mm: Wire up hpte_removebolted for powernv Oliver O'Halloran
2017-04-11 17:42   ` Oliver O'Halloran
     [not found]   ` <20170411174233.21902-9-oohall-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2017-04-11 22:50     ` Anton Blanchard
2017-04-11 22:50       ` Anton Blanchard
2017-04-12  0:18       ` Stephen Rothwell
2017-04-12  0:18         ` Stephen Rothwell
2017-04-12  3:30         ` Rashmica Gupta
2017-04-12  3:30           ` Rashmica Gupta
2017-04-12  1:53   ` Balbir Singh
2017-04-12  1:53     ` Balbir Singh
2017-04-13  4:21     ` Oliver O'Halloran
2017-04-13  4:21       ` Oliver O'Halloran
2017-04-13 10:10       ` Michael Ellerman
2017-04-13 10:10         ` Michael Ellerman
2017-04-11 17:42 ` [PATCH 9/9] powerpc: Add pmem API support Oliver O'Halloran
2017-04-11 17:42   ` Oliver O'Halloran
2017-04-11 18:22 ` ZONE_DEVICE and pmem API support for powerpc Dan Williams
2017-04-11 18:22   ` Dan Williams
2017-04-12  9:14   ` Oliver O'Halloran [this message]
2017-04-12  9:14     ` Oliver O'Halloran
2017-04-12  1:10 ` Stephen Rothwell
2017-04-12  1:10   ` Stephen Rothwell

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='CAOSf1CEtUHeQspR9=sRKJQxxsH==_82L8AzUy10aUj=d=e0_kA@mail.gmail.com' \
    --to=oohall@gmail.com \
    --cc=arbab@linux.vnet.ibm.com \
    --cc=bsingharora@gmail.com \
    --cc=dan.j.williams@intel.com \
    --cc=linux-nvdimm@lists.01.org \
    --cc=linuxppc-dev@lists.ozlabs.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.