On Tue, Nov 19, 2019 at 7:19 PM Aneesh Kumar K.V
wrote:
>
> On 11/19/19 11:28 PM, Dan Williams wrote:
> > On Mon, Nov 18, 2019 at 1:52 AM Aneesh Kumar K.V
> > wrote:
> >>
> >> Dan Williams writes:
> >>
> >>> On S
On Mon, Nov 18, 2019 at 1:52 AM Aneesh Kumar K.V
wrote:
>
> Dan Williams writes:
>
> > On Sat, Nov 16, 2019 at 4:15 AM Aneesh Kumar K.V
> > wrote:
> >>
>
>
>
>
> >>
> >> Considering the direct-map map size is not going to be u
On Mon, Nov 18, 2019 at 7:29 PM Andrew Donnellan wrote:
>
> On 19/11/19 1:48 pm, Alastair D'Silva wrote:
> > On Tue, 2019-11-19 at 10:47 +1100, Andrew Donnellan wrote:
> >> On 15/11/19 3:35 am, Dan Williams wrote:
> >>>> Have you discussed with the direc
On Mon, Nov 18, 2019 at 3:48 PM Andrew Donnellan wrote:
>
> On 15/11/19 3:35 am, Dan Williams wrote:
> >> Have you discussed with the directory owner if it's ok to split the
> >> driver over several files?
> >
> > My thought is to establish drivers/ope
On Sat, Nov 16, 2019 at 4:15 AM Aneesh Kumar K.V
wrote:
>
>
> Hi Dan,
>
> "Aneesh Kumar K.V" writes:
>
> > Dan Williams writes:
> >
> >> On Wed, Oct 30, 2019 at 10:35 PM Aneesh Kumar K.V
> >> wrote:
> >> [..]
> &
On Thu, Oct 24, 2019 at 9:49 PM Alastair D'Silva wrote:
>
> From: Alastair D'Silva
>
> These functions don't exist, so remove the prototypes for them.
>
> Signed-off-by: Alastair D'Silva
Looks good, applied.
Some quick feedback on your intro concerns...
On Thu, Nov 14, 2019 at 5:41 AM Frederic Barrat wrote:
>
> Hi Alastair,
>
> The patch is huge and could/should probably be split in smaller pieces
Yeah, it's a must. Split the minimum viable infrastructure by topic
and then follow on with per-feature
On Wed, Nov 13, 2019 at 2:49 PM John Hubbard wrote:
>
> On 11/13/19 2:00 PM, Dan Williams wrote:
> ...
> >> Ugh, when did all this HMM specific manipulation sneak into the
> >> generic ZONE_DEVICE path? It used to be gated by pgmap type with its
> >> own
On Wed, Nov 13, 2019 at 11:23 AM Dan Williams wrote:
>
> On Tue, Nov 12, 2019 at 8:27 PM John Hubbard wrote:
> >
> > An upcoming patch changes and complicates the refcounting and
> > especially the "put page" aspects of it. In order to keep
> > everything
On Tue, Nov 12, 2019 at 8:27 PM John Hubbard wrote:
>
> An upcoming patch changes and complicates the refcounting and
> especially the "put page" aspects of it. In order to keep
> everything clean, refactor the devmap page release routines:
>
> * Rename put_devmap_managed_page() to page_is_devmap_
On Wed, Nov 13, 2019 at 2:43 AM Jan Kara wrote:
>
> On Tue 12-11-19 20:26:56, John Hubbard wrote:
> > Introduce pin_user_pages*() variations of get_user_pages*() calls,
> > and also pin_longterm_pages*() variations.
> >
> > These variants all set FOLL_PIN, which is also introduced, and
> > thoroug
On Tue, Nov 12, 2019 at 5:08 PM John Hubbard wrote:
>
> On 11/12/19 4:58 PM, Dan Williams wrote:
> ...
> >>> It's not redundant relative to upstream which does not do anything the
> >>> FOLL_LONGTERM in the gup-slow path... but I have not looked at patches
&g
On Tue, Nov 12, 2019 at 3:43 PM Jason Gunthorpe wrote:
>
> On Tue, Nov 12, 2019 at 02:45:51PM -0800, Dan Williams wrote:
> > On Tue, Nov 12, 2019 at 2:43 PM John Hubbard wrote:
> > >
> > > On 11/12/19 12:43 PM, Jason Gunthorpe wrote:
> > > ...
&g
On Tue, Nov 12, 2019 at 3:08 PM John Hubbard wrote:
>
> On 11/12/19 2:43 PM, Dan Williams wrote:
> ...
> > Ah, sorry. This was the first time I had looked at this series and
> > jumped in without reading the background.
> >
> > Your patch as is looks ok, I assume
On Tue, Nov 12, 2019 at 2:43 PM John Hubbard wrote:
>
> On 11/12/19 12:43 PM, Jason Gunthorpe wrote:
> ...
> >> -}
> >> +ret = get_user_pages_remote(NULL, mm, vaddr, 1, flags | FOLL_LONGTERM,
> >> +page, vmas, NULL);
> >> +/*
> >> + * The lif
On Tue, Nov 12, 2019 at 2:24 PM John Hubbard wrote:
>
> On 11/12/19 1:57 PM, Dan Williams wrote:
> ...
> >> diff --git a/drivers/vfio/vfio_iommu_type1.c
> >> b/drivers/vfio/vfio_iommu_type1.c
> >> index d864277ea16f..017689b7c32b 100644
> >> ---
On Mon, Nov 11, 2019 at 4:07 PM John Hubbard wrote:
>
> As it says in the updated comment in gup.c: current FOLL_LONGTERM
> behavior is incompatible with FAULT_FLAG_ALLOW_RETRY because of the
> FS DAX check requirement on vmas.
>
> However, the corresponding restriction in get_user_pages_remote()
On Mon, Nov 11, 2019 at 9:37 PM Dan Williams wrote:
>
> On Mon, Nov 11, 2019 at 3:34 AM Aneesh Kumar K.V
> wrote:
> >
> > "Alastair D'Silva" writes:
> >
> > > From: Alastair D'Silva
> > >
> > > This driver exposes LPC me
On Mon, Nov 11, 2019 at 3:34 AM Aneesh Kumar K.V
wrote:
>
> "Alastair D'Silva" writes:
>
> > From: Alastair D'Silva
> >
> > This driver exposes LPC memory on OpenCAPI SCM cards
> > as an NVDIMM, allowing the existing nvram infrastructure
> > to be used.
> >
> > Signed-off-by: Alastair D'Silva
>
On Fri, Nov 8, 2019 at 2:22 AM David Hildenbrand wrote:
>
> On 08.11.19 08:14, David Hildenbrand wrote:
> > On 08.11.19 06:09, Dan Williams wrote:
> >> On Thu, Nov 7, 2019 at 2:07 PM David Hildenbrand wrote:
> >>>
> >>> On 07.11.19 19:22, Davi
On Thu, Nov 7, 2019 at 2:07 PM David Hildenbrand wrote:
>
> On 07.11.19 19:22, David Hildenbrand wrote:
> >
> >
> >> Am 07.11.2019 um 16:40 schrieb Dan Williams :
> >>
> >> On Thu, Oct 24, 2019 at 5:12 AM David Hildenbrand
> >> wrote:
&
On Thu, Oct 24, 2019 at 5:12 AM David Hildenbrand wrote:
>
> Right now, ZONE_DEVICE memory is always set PG_reserved. We want to
> change that.
>
> KVM has this weird use case that you can map anything from /dev/mem
> into the guest. pfn_valid() is not a reliable check whether the memmap
> was ini
On Tue, Nov 5, 2019 at 4:03 PM Sean Christopherson
wrote:
>
> On Tue, Nov 05, 2019 at 03:43:29PM -0800, Dan Williams wrote:
> > On Tue, Nov 5, 2019 at 3:30 PM Dan Williams
> > wrote:
> > >
> > > On Tue, Nov 5, 2019 at 3:13 PM Sean Christopherson
> >
On Tue, Nov 5, 2019 at 3:30 PM Dan Williams wrote:
>
> On Tue, Nov 5, 2019 at 3:13 PM Sean Christopherson
> wrote:
> >
> > On Tue, Nov 05, 2019 at 03:02:40PM -0800, Dan Williams wrote:
> > > On Tue, Nov 5, 2019 at 12:31 PM David Hildenbrand
> > > wrote:
On Tue, Nov 5, 2019 at 3:13 PM Sean Christopherson
wrote:
>
> On Tue, Nov 05, 2019 at 03:02:40PM -0800, Dan Williams wrote:
> > On Tue, Nov 5, 2019 at 12:31 PM David Hildenbrand wrote:
> > > > The scarier code (for me) is transparent_hugepage_adjust() and
> > &g
On Tue, Nov 5, 2019 at 12:31 PM David Hildenbrand wrote:
>
> >>> I think I know what's going wrong:
> >>>
> >>> Pages that are pinned via gfn_to_pfn() and friends take a references,
> >>> however are often released via
> >>> kvm_release_pfn_clean()/kvm_release_pfn_dirty()/kvm_release_page_clean().
ges PG_reserved.
>
> Cc: Paolo Bonzini
> Cc: "Radim Krčmář"
> Cc: Michal Hocko
> Cc: Dan Williams
> Cc: KarimAllah Ahmed
> Signed-off-by: David Hildenbrand
> ---
> virt/kvm/kvm_main.c | 10 --
> 1 file changed, 8 insertions(+), 2 deletions(-)
&
_reserved.
>
> Cc: Paolo Bonzini
> Cc: "Radim Krčmář"
> Cc: Sean Christopherson
> Cc: Vitaly Kuznetsov
> Cc: Wanpeng Li
> Cc: Jim Mattson
> Cc: Joerg Roedel
> Cc: Thomas Gleixner
> Cc: Ingo Molnar
> Cc: Borislav Petkov
> Cc: "H. Peter Anvin
t enough protection.
>
> Please note that hardware errors (PG_hwpoison) are not memory holes and
> not affected by this change when offlining.
>
> Cc: Andrew Morton
> Cc: Michal Hocko
> Cc: Oscar Salvador
> Cc: Pavel Tatashin
> Cc: Dan Williams
> Cc: Anshuman K
On Thu, Oct 31, 2019 at 1:38 AM Aneesh Kumar K.V
wrote:
>
> On 10/31/19 12:00 PM, Dan Williams wrote:
> > On Wed, Oct 30, 2019 at 10:35 PM Aneesh Kumar K.V
> > wrote:
> > [..]
>
> >
> >
> > All that said, the x86 vmemmap_populate() falls back to u
On Wed, Oct 30, 2019 at 10:35 PM Aneesh Kumar K.V
wrote:
[..]
> > True, for the pfn device and the device-dax mapping size, but I'm
> > suggesting adding another instance of alignment control at the raw
> > namespace level. That would need to be disconnected from the
> > device-dax page mapping gr
On Mon, Oct 28, 2019 at 9:35 PM Aneesh Kumar K.V
wrote:
>
> On 10/29/19 4:38 AM, Dan Williams wrote:
> > On Mon, Oct 28, 2019 at 2:48 AM Aneesh Kumar K.V
> > wrote:
> >>
> >> The page size used to map the namespace is arch dependent. For example
> >>
On Mon, Oct 28, 2019 at 2:48 AM Aneesh Kumar K.V
wrote:
>
> The page size used to map the namespace is arch dependent. For example
> architectures like ppc64 use 16MB page size for direct-mapping. If the
> namespace
> size is not aligned to the mapping page size, we can observe kernel crash
> dur
On Wed, Oct 23, 2019 at 10:28 AM David Hildenbrand wrote:
>
> >> I dislike this for three reasons
> >>
> >> a) It does not protect against any races, really, it does not improve
> >> things.
> >> b) We do have the exact same problem with pfn_to_online_page(). As long as
> >> we
> >>don't hol
On Wed, Oct 23, 2019 at 12:26 AM David Hildenbrand wrote:
>
> On 22.10.19 23:54, Dan Williams wrote:
> > Hi David,
> >
> > Thanks for tackling this!
>
> Thanks for having a look :)
>
> [...]
>
>
> >> I am probably a little bit too careful (but
Hi David,
Thanks for tackling this!
On Tue, Oct 22, 2019 at 10:13 AM David Hildenbrand wrote:
>
> This series is based on [2], which should pop up in linux/next soon:
> https://lkml.org/lkml/2019/10/21/1034
>
> This is the result of a recent discussion with Michal ([1], [2]). Right
> now
On Mon, Sep 23, 2019 at 9:25 PM Aneesh Kumar K.V
wrote:
>
> In later patch, we want to use hash_transparent_hugepage() in a kernel module.
> Export two related functions.
>
Looks good, thanks.
On Sun, Sep 22, 2019 at 5:04 AM Michael Ellerman wrote:
>
>
>
> On 21 September 2019 4:31:16 am AEST, Dan Williams
> wrote:
> >On Fri, Sep 20, 2019 at 11:18 AM Qian Cai wrote:
> >>
> >> On Fri, 2019-09-20 at 19:55 +0530, Aneesh Kumar K.V wrote:
>
On Fri, Sep 20, 2019 at 11:18 AM Qian Cai wrote:
>
> On Fri, 2019-09-20 at 19:55 +0530, Aneesh Kumar K.V wrote:
> > Qian Cai writes:
> >
> > > The linux-next commit "libnvdimm/dax: Pick the right alignment default
> > > when
> > > creating dax devices" causes powerpc failed to build with this co
On Tue, Sep 17, 2019 at 12:40 AM Aneesh Kumar K.V
wrote:
>
> On 9/16/19 11:28 PM, Dan Williams wrote:
> > On Mon, Sep 9, 2019 at 11:29 PM Aneesh Kumar K.V
> > wrote:
> >>
> >> With PFN_MODE_PMEM namespace, the memmap area is allocated from the device
> >
On Mon, Sep 9, 2019 at 11:29 PM Aneesh Kumar K.V
wrote:
>
> With PFN_MODE_PMEM namespace, the memmap area is allocated from the device
> area. Some architectures map the memmap area with large page size. On
> architectures like ppc64, 16MB page for memap mapping can map 262144 pfns.
> This maps a
On Mon, Sep 9, 2019 at 11:29 PM Aneesh Kumar K.V
wrote:
>
> With commit: 7cc7867fb061 ("mm/devm_memremap_pages: enable sub-section remap")
> pmem namespaces are remapped in 2M chunks. On architectures like ppc64 we
> can map the memmap area using 16MB hugepage size and that can cover
> a memory ra
On Tue, Sep 10, 2019 at 1:31 AM Aneesh Kumar K.V
wrote:
>
> On 9/10/19 1:40 PM, Dan Williams wrote:
> > On Mon, Sep 9, 2019 at 11:29 PM Aneesh Kumar K.V
> > wrote:
> >>
> >> With PFN_MODE_PMEM namespace, the memmap area is allocated from the device
> >
On Mon, Sep 9, 2019 at 11:29 PM Aneesh Kumar K.V
wrote:
>
> With PFN_MODE_PMEM namespace, the memmap area is allocated from the device
> area. Some architectures map the memmap area with large page size. On
> architectures like ppc64, 16MB page for memap mapping can map 262144 pfns.
> This maps a
On Mon, Aug 19, 2019 at 2:32 AM Aneesh Kumar K.V
wrote:
>
> Aneesh Kumar K.V writes:
>
> > Dan Williams writes:
> >
> >> On Fri, Aug 9, 2019 at 12:45 AM Aneesh Kumar K.V
> >> wrote:
> >>>
> >>
>
> ...
>
> >>&g
On Mon, Aug 19, 2019 at 12:07 AM Aneesh Kumar K.V
wrote:
>
> Dan Williams writes:
>
> > On Tue, Aug 13, 2019 at 9:22 PM Dan Williams
> > wrote:
> >>
> >> Hi Aneesh, logic looks correct but there are some cleanups I'd like to
> >> see and a
On Fri, Aug 9, 2019 at 12:45 AM Aneesh Kumar K.V
wrote:
>
> Use PAGE_SIZE instead of SZ_4K and sizeof(struct page) instead of 64.
> If we have a kernel built with different struct page size the previous
> patch should handle marking the namespace disabled.
Each of these changes carry independent
On Tue, Aug 13, 2019 at 9:22 PM Dan Williams wrote:
>
> Hi Aneesh, logic looks correct but there are some cleanups I'd like to
> see and a lead-in patch that I attached.
>
> I've started prefixing nvdimm patches with:
>
> libnvdimm/$component:
>
> ...sin
ed comment here to explain the special
translation of error codes.
> + ret = nd_btt_probe(dev, ndns);
> + if (ret == 0)
> return -ENXIO;
> + else if (ret == -EOPNOTSUPP)
Are there cases where the btt driver needs to return EOPNOTSUPP? I'd
otherwi
On Tue, Aug 6, 2019 at 11:00 PM Aneesh Kumar K.V
wrote:
>
> On 8/7/19 10:22 AM, Dan Williams wrote:
> > On Tue, Aug 6, 2019 at 9:17 PM Aneesh Kumar K.V
> > wrote:
> >>
> >> On 8/7/19 9:43 AM, Dan Williams wrote:
> >>> On Tue, Aug
On Tue, Aug 6, 2019 at 9:17 PM Aneesh Kumar K.V
wrote:
>
> On 8/7/19 9:43 AM, Dan Williams wrote:
> > On Tue, Aug 6, 2019 at 9:00 PM Aneesh Kumar K.V
> > wrote:
> >>
> >> ndctl utility requires the ndbus to have unique names. If not while
> >> enume
On Tue, Aug 6, 2019 at 9:00 PM Aneesh Kumar K.V
wrote:
>
> ndctl utility requires the ndbus to have unique names. If not while
> enumerating the bus in userspace it drops bus with similar names.
> This results in us not listing devices beneath the bus.
It does?
>
> Signed-off-by: Aneesh Kumar K.
On Thu, Jul 18, 2019 at 12:49 AM Aneesh Kumar K.V
wrote:
>
> "Oliver O'Halloran" writes:
>
> > On Tue, Jul 16, 2019 at 7:08 PM Aneesh Kumar K.V
> > wrote:
> >>
> >> This is similar to what ACPI does. Nvdimm layer doesn't bring the SCM
> >> device
> >> numa node online. Hence we need to make sur
On Tue, May 21, 2019 at 2:51 AM Aneesh Kumar K.V
wrote:
>
> Dan Williams writes:
>
> > On Mon, May 13, 2019 at 9:46 PM Aneesh Kumar K.V
> > wrote:
> >>
> >> On 5/14/19 9:42 AM, Dan Williams wrote:
> >> > On Mon, May 13, 2019 at 9:05 PM Aneesh
On Mon, May 13, 2019 at 9:46 PM Aneesh Kumar K.V
wrote:
>
> On 5/14/19 9:42 AM, Dan Williams wrote:
> > On Mon, May 13, 2019 at 9:05 PM Aneesh Kumar K.V
> > wrote:
> >>
> >> On 5/14/19 9:28 AM, Dan Williams wrote:
> >>> On Mon, May 1
On Sun, May 19, 2019 at 1:55 AM Aneesh Kumar K.V
wrote:
>
>
> Hi Dan,
>
> "Aneesh Kumar K.V" writes:
>
> > On 5/17/19 8:19 PM, Vaibhav Jain wrote:
> >> Hi Aneesh,
> >>
>
>
>
> >>
> >>> + /*
> >>> +* Check whether the we support the alignment. For Dax if the
> >>> +* superblock alig
On Mon, May 13, 2019 at 7:55 PM Aneesh Kumar K.V
wrote:
>
> We already add the start_pad to the resource->start but fails to section
> align the start. This make sure with altmap we compute the right first
> pfn when start_pad is zero and we are doing an align down of start address.
>
> Signed-off
[ add Keith who was looking at something similar ]
On Mon, May 13, 2019 at 7:54 PM Aneesh Kumar K.V
wrote:
>
> When we initialize the namespace, if we support altmap, we don't initialize
> all the
> backing struct page where as while releasing the namespace we look at some of
> these uninitilize
On Mon, May 13, 2019 at 9:05 PM Aneesh Kumar K.V
wrote:
>
> On 5/14/19 9:28 AM, Dan Williams wrote:
> > On Mon, May 13, 2019 at 7:56 PM Aneesh Kumar K.V
> > wrote:
> >>
> >> The nfpn related change is needed to fix the kernel message
> >>
> >
On Mon, May 13, 2019 at 7:56 PM Aneesh Kumar K.V
wrote:
>
> The nfpn related change is needed to fix the kernel message
>
> "number of pfns truncated from 2617344 to 163584"
>
> The change makes sure the nfpns stored in the superblock is right value.
>
> Signed-off-by: Aneesh Kumar K.V
> ---
> d
On Wed, May 8, 2019 at 12:22 AM David Hildenbrand wrote:
>
>
> >> drivers/base/node.c | 18 +-
> >> include/linux/node.h | 5 ++---
> >> 2 files changed, 7 insertions(+), 16 deletions(-)
> >>
> >> diff --git a/drivers/base/node.c b/drivers/base/node.c
> >> index 04fdfa99b8bc..9b
age does not require special care so you can drop
that comment. The only place it's used in the subsection patches is to
lookup the node-id, but it turns out that the resulting node-id is
then never used.
With the ZONE_DEVICE mention dropped out of changelog you can add:
Reviewed-by: Dan Williams
lk, void *arg)
>
> /*
> * Unregister memory block device under all nodes that it spans.
> + * Has to be called with mem_sysfs_mutex held (due to unlinked_nodes).
Given this comment can bitrot relative to the implementation lets
instead add an explicit:
lockdep_assert_held(&mem_sysfs_mutex);
With that you can add:
Reviewed-by: Dan Williams
__remove_section(struct zone *zone, struct
> mem_section *ms,
> if (WARN_ON_ONCE(!valid_section(ms)))
> return;
>
> - unregister_memory_section(ms);
> -
> scn_nr = __section_nr(ms);
> start_pfn = section_nr_to_pfn((unsigned long)scn_nr);
> __remove_zone(zone, start_pfn);
> @@ -1844,6 +1842,9 @@ void __ref __remove_memory(int nid, u64 start, u64 size)
> memblock_free(start, size);
> memblock_remove(start, size);
>
> + /* remove memory block devices before removing memory */
> + hotplug_memory_unregister(start, size);
> +
> arch_remove_memory(nid, start, size, NULL);
> __release_memory_resource(start, size);
Other than the BUG_ON concern you can add
Reviewed-by: Dan Williams
On Tue, May 7, 2019 at 2:24 PM David Hildenbrand wrote:
>
> On 07.05.19 23:19, Dan Williams wrote:
> > On Tue, May 7, 2019 at 11:38 AM David Hildenbrand wrote:
> >>
> >> No longer needed, the callers of arch_add_memory() can handle this
> >> manually.
>
On Tue, May 7, 2019 at 11:38 AM David Hildenbrand wrote:
>
> Only memory to be added to the buddy and to be onlined/offlined by
> user space using memory block devices needs (and should have!) memory
> block devices.
>
> Factor out creation of memory block devices Create all devices after
> arch_a
On Tue, May 7, 2019 at 11:38 AM David Hildenbrand wrote:
>
> No longer needed, the callers of arch_add_memory() can handle this
> manually.
>
> Cc: Andrew Morton
> Cc: David Hildenbrand
> Cc: Michal Hocko
> Cc: Oscar Salvador
> Cc: Pavel Tatashin
> Cc: Wei Yang
> Cc: Joonsoo Kim
> Cc: Qian
On Tue, May 7, 2019 at 11:38 AM David Hildenbrand wrote:
>
> Let's prepare for better error handling while adding memory by allowing
> to use arch_remove_memory() and __remove_pages() even if
> CONFIG_MEMORY_HOTREMOVE is not set. CONFIG_MEMORY_HOTREMOVE effectively
> covers
> - Offlining of system
On Tue, May 7, 2019 at 1:47 PM David Hildenbrand wrote:
>
> On 07.05.19 22:46, Dan Williams wrote:
> > On Tue, May 7, 2019 at 11:38 AM David Hildenbrand wrote:
> >>
> >> Will come in handy when wanting to handle errors after
> >> arch_add_memory().
&g
On Tue, May 7, 2019 at 11:38 AM David Hildenbrand wrote:
>
> Will come in handy when wanting to handle errors after
> arch_add_memory().
>
> Cc: Martin Schwidefsky
> Cc: Heiko Carstens
> Cc: Andrew Morton
> Cc: Michal Hocko
> Cc: Mike Rapoport
> Cc: David Hildenbrand
> Cc: Vasily Gorbik
> C
ichal Hocko
> Cc: David Hildenbrand
> Cc: Pavel Tatashin
> Cc: Qian Cai
> Cc: Wei Yang
> Cc: Arun KS
> Cc: Mathieu Malaterre
> Signed-off-by: David Hildenbrand
Reviewed-by: Dan Williams
On Tue, May 7, 2019 at 12:38 PM David Hildenbrand wrote:
>
> On 07.05.19 21:21, David Hildenbrand wrote:
> > On 07.05.19 21:04, Dan Williams wrote:
> >> On Tue, May 7, 2019 at 11:38 AM David Hildenbrand wrote:
> >>>
> >>> We only want memory bl
On Tue, May 7, 2019 at 11:38 AM David Hildenbrand wrote:
>
> We only want memory block devices for memory to be onlined/offlined
> (add/remove from the buddy). This is required so user space can
> online/offline memory and kdump gets notified about newly onlined memory.
>
> Only such memory has th
On Tue, May 7, 2019 at 4:50 AM Aneesh Kumar K.V
wrote:
>
>
> Hi Dan,
>
> "Aneesh Kumar K.V" writes:
>
> > This move the dependency to DEV_DAX_PMEM_COMPAT such that only
> > if DEV_DAX_PMEM is built as module we can allow the compat support.
> >
> > This allows to test the new code easily in a emu
On Thu, Apr 25, 2019 at 12:32 AM Jan Kara wrote:
>
> On Wed 24-04-19 11:13:48, Dan Williams wrote:
> > On Wed, Apr 24, 2019 at 10:38 AM Matthew Wilcox wrote:
> > >
> > > On Wed, Apr 24, 2019 at 10:13:15AM -0700, Dan Williams wrote:
> > > > I think unal
On Wed, Apr 24, 2019 at 6:37 PM Aneesh Kumar K.V
wrote:
>
> On 4/24/19 11:43 PM, Dan Williams wrote:
> > On Wed, Apr 24, 2019 at 10:38 AM Matthew Wilcox wrote:
> >>
> >> On Wed, Apr 24, 2019 at 10:13:15AM -0700, Dan Williams wrote:
> >>> I think unal
On Wed, Apr 24, 2019 at 10:38 AM Matthew Wilcox wrote:
>
> On Wed, Apr 24, 2019 at 10:13:15AM -0700, Dan Williams wrote:
> > I think unaligned addresses have always been passed to
> > vmf_insert_pfn_pmd(), but nothing cared until this patch. I *think*
> > the only change
On Tue, Apr 2, 2019 at 4:51 AM Aneesh Kumar K.V
wrote:
>
> With some architectures like ppc64, set_pmd_at() cannot cope with
> a situation where there is already some (different) valid entry present.
>
> Use pmdp_set_access_flags() instead to modify the pfn which is built to
> deal with modifying
real situation is clearer.
Looks good to me.
Acked-by: Dan Williams
nging all the
> arch code). SECTION_MASK is unused, so it can just go.
Looks good to me. So good that it collides with a similar change in
the "sub-section" support series.
Acked-by: Dan Williams
On Mon, Apr 8, 2019 at 2:39 AM Aneesh Kumar K.V
wrote:
>
>
> Hi Dan,
>
> Dan Williams writes:
>
> > On Wed, Mar 13, 2019 at 2:58 AM Jan Kara wrote:
> >>
> >> On Wed 13-03-19 10:17:17, Aneesh Kumar K.V wrote:
> >> >
> >>
On Fri, Mar 29, 2019 at 10:42 PM Aneesh Kumar K.V
wrote:
>
> This move the dependency to DEV_DAX_PMEM_COMPAT such that only
> if DEV_DAX_PMEM is built as module we can allow the compat support.
>
> This allows to test the new code easily in a emulation setup where we
> often build things without m
On Mon, Mar 25, 2019 at 3:22 PM Ira Weiny wrote:
[..]
> FWIW this thread is making me think my original patch which simply implemented
> get_user_pages_fast_longterm() would be more clear. There is some evidence
> that the GUP API was trending that way (see get_user_pages_remote). That
> seems
On Mon, Mar 25, 2019 at 7:21 AM Ira Weiny wrote:
[..]
> > > @@ -1268,10 +1246,14 @@ static long check_and_migrate_cma_pages(unsigned
> > > long start, long nr_pages,
> > > putback_movable_pages(&cma_page_list);
> > > }
> > > /*
> > >
On Sun, Mar 17, 2019 at 7:36 PM wrote:
>
> From: Ira Weiny
>
> Use the new FOLL_LONGTERM to get_user_pages_fast() to protect against
> FS DAX pages being mapped.
>
> Signed-off-by: Ira Weiny
Looks good modulo potential __get_user_pages_fast() suggestion.
On Sun, Mar 17, 2019 at 7:36 PM wrote:
>
> From: Ira Weiny
>
> Use the new FOLL_LONGTERM to get_user_pages_fast() to protect against
> FS DAX pages being mapped.
>
> Signed-off-by: Ira Weiny
> ---
> drivers/infiniband/hw/hfi1/user_pages.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletio
On Sun, Mar 17, 2019 at 7:36 PM wrote:
>
> From: Ira Weiny
>
> DAX pages were previously unprotected from longterm pins when users
> called get_user_pages_fast().
>
> Use the new FOLL_LONGTERM flag to check for DEVMAP pages and fall
> back to regular GUP processing if a DEVMAP page is encountered
On Sun, Mar 17, 2019 at 7:36 PM wrote:
>
> From: Ira Weiny
>
> To facilitate additional options to get_user_pages_fast() change the
> singular write parameter to be gup_flags.
>
> This patch does not change any functionality. New functionality will
> follow in subsequent patches.
>
> Some of the
viously used.
>
> Signed-off-by: Ira Weiny
Looks good,
Reviewed-by: Dan Williams
On Sun, Mar 17, 2019 at 7:36 PM wrote:
>
> From: Ira Weiny
>
> Rather than have a separate get_user_pages_longterm() call,
> introduce FOLL_LONGTERM and change the longterm callers to use
> it.
>
> This patch does not change any functionality.
>
> FOLL_LONGTERM can only be supported with get_user
On Wed, Mar 20, 2019 at 8:09 PM Oliver wrote:
>
> On Thu, Mar 21, 2019 at 7:57 AM Dan Williams wrote:
> >
> > On Wed, Mar 20, 2019 at 8:34 AM Dan Williams
> > wrote:
> > >
> > > On Wed, Mar 20, 2019 at 1:09 AM Aneesh Kumar K.V
> > &g
On Wed, Mar 20, 2019 at 8:34 AM Dan Williams wrote:
>
> On Wed, Mar 20, 2019 at 1:09 AM Aneesh Kumar K.V
> wrote:
> >
> > Aneesh Kumar K.V writes:
> >
> > > Dan Williams writes:
> > >
> > >>
> > >>> Now what wi
On Wed, Mar 20, 2019 at 1:09 AM Aneesh Kumar K.V
wrote:
>
> Aneesh Kumar K.V writes:
>
> > Dan Williams writes:
> >
> >>
> >>> Now what will be page size used for mapping vmemmap?
> >>
> >> That's up to the architect
On Tue, Mar 19, 2019 at 1:45 AM Kirill A. Shutemov wrote:
>
> On Wed, Mar 13, 2019 at 09:07:13AM -0700, Dan Williams wrote:
> > On Wed, Mar 6, 2019 at 4:46 AM Aneesh Kumar K.V
> > wrote:
> > >
> > > On 3/6/19 5:14 PM, Michal Suchánek wrote:
> &
On Wed, Mar 13, 2019 at 8:45 PM Aneesh Kumar K.V
wrote:
[..]
> >> Now w.r.t to failures, can device-dax do an opportunistic huge page
> >> usage?
> >
> > device-dax explicitly disclaims the ability to do opportunistic mappings.
> >
> >> I haven't looked at the device-dax details fully yet. Do we m
On Wed, Mar 6, 2019 at 4:46 AM Aneesh Kumar K.V
wrote:
>
> On 3/6/19 5:14 PM, Michal Suchánek wrote:
> > On Wed, 06 Mar 2019 14:47:33 +0530
> > "Aneesh Kumar K.V" wrote:
> >
> >> Dan Williams writes:
> >>
> >>> On Thu, Feb 28, 2019
On Wed, Mar 6, 2019 at 1:18 AM Aneesh Kumar K.V
wrote:
>
> Dan Williams writes:
>
> > On Thu, Feb 28, 2019 at 1:40 AM Oliver wrote:
> >>
> >> On Thu, Feb 28, 2019 at 7:35 PM Aneesh Kumar K.V
> >> wrote:
> >> >
> >> >
On Wed, Mar 13, 2019 at 2:58 AM Jan Kara wrote:
>
> On Wed 13-03-19 10:17:17, Aneesh Kumar K.V wrote:
> >
> > Hi Dan/Andrew/Jan,
> >
> > "Aneesh Kumar K.V" writes:
> >
> > > Architectures like ppc64 use the deposited page table to store hardware
> > > page table slot information. Make sure we dep
On Thu, Feb 28, 2019 at 1:40 AM Oliver wrote:
>
> On Thu, Feb 28, 2019 at 7:35 PM Aneesh Kumar K.V
> wrote:
> >
> > Add a flag to indicate the ability to do huge page dax mapping. On
> > architecture
> > like ppc64, the hypervisor can disable huge page support in the guest. In
> > such a case, w
d by rolling the functionality into a
> seperate driver so here we are...
>
> Acked-by: Dan Williams
> Signed-off-by: Oliver O'Halloran
> ---
> The alternative implementation here is that we have the pseries code
> do the h-calls and craft a pmem-region@ node based on t
201 - 300 of 465 matches
Mail list logo
