search for: weinies

On Wed, Jun 26, 2019 at 02:27:15PM +0200, Christoph Hellwig wrote: > The functionality is identical to the one currently open coded in > device-dax. > > Signed-off-by: Christoph Hellwig <hch at lst.de> > Reviewed-by: Ira Weiny <ira.weiny at intel.com> > --- > drivers/dax/dax-private.h | 4 ---- > drivers/dax/device.c | 43

On Fri, Jun 28, 2019 at 09:27:44AM -0700, Dan Williams wrote: > On Fri, Jun 28, 2019 at 8:39 AM Jason Gunthorpe <jgg at mellanox.com> wrote: > > > > On Wed, Jun 26, 2019 at 02:27:15PM +0200, Christoph Hellwig wrote: > > > The functionality is identical to the one currently open coded in > > > device-dax. > > > > > > Signed-off-by: Christoph

On Fri, Jun 28, 2019 at 10:08 AM Dan Williams <dan.j.williams at intel.com> wrote: > > On Fri, Jun 28, 2019 at 10:02 AM Jason Gunthorpe <jgg at mellanox.com> wrote: > > > > On Fri, Jun 28, 2019 at 09:27:44AM -0700, Dan Williams wrote: > > > On Fri, Jun 28, 2019 at 8:39 AM Jason Gunthorpe <jgg at mellanox.com> wrote: > > > > > > >

[ add Ira ] On Wed, Jun 26, 2019 at 5:27 AM Christoph Hellwig <hch at lst.de> wrote: > > The code hasn't been used since it was added to the tree, and doesn't > appear to actually be usable. > > Signed-off-by: Christoph Hellwig <hch at lst.de> > Reviewed-by: Jason Gunthorpe <jgg at mellanox.com> > Acked-by: Michal Hocko <mhocko at suse.com>

On Tue, Feb 19, 2019 at 09:30:33PM -0800, ira.weiny at intel.com wrote: > From: Ira Weiny <ira.weiny at intel.com> > > Resending these as I had only 1 minor comment which I believe we have covered > in this series. I was anticipating these going through the mm tree as they > depend on a cleanup patch there and the IB changes are very minor. But they > could just as well

On Thu, Jun 13, 2019 at 06:23:04PM -0700, John Hubbard wrote: > On 6/13/19 5:43 PM, Ira Weiny wrote: > > On Thu, Jun 13, 2019 at 07:58:29PM +0000, Jason Gunthorpe wrote: > >> On Thu, Jun 13, 2019 at 12:53:02PM -0700, Ralph Campbell wrote: > >>> > ... > >> Hum, so the only thing this config does is short circuit here: > >> > >> static

On Wed, Jun 26, 2019 at 02:27:10PM +0200, Christoph Hellwig wrote: > Just check if there is a ->page_free operation set and take care of the > static key enable, as well as the put using device managed resources. > Also check that a ->page_free is provided for the pgmaps types that > require it, and check for a valid type as well while we are at it. > > Note that this also

On Thu, Jun 13, 2019 at 07:58:29PM +0000, Jason Gunthorpe wrote: > On Thu, Jun 13, 2019 at 12:53:02PM -0700, Ralph Campbell wrote: > > > > On 6/13/19 12:44 PM, Jason Gunthorpe wrote: > > > On Thu, Jun 13, 2019 at 11:43:21AM +0200, Christoph Hellwig wrote: > > > > The code hasn't been used since it was added to the tree, and doesn't > > > >

On Fri, Jun 28, 2019 at 8:39 AM Jason Gunthorpe <jgg at mellanox.com> wrote: > > On Wed, Jun 26, 2019 at 02:27:15PM +0200, Christoph Hellwig wrote: > > The functionality is identical to the one currently open coded in > > device-dax. > > > > Signed-off-by: Christoph Hellwig <hch at lst.de> > > Reviewed-by: Ira Weiny <ira.weiny at intel.com>

On Fri, Jun 28, 2019 at 10:02 AM Jason Gunthorpe <jgg at mellanox.com> wrote: > > On Fri, Jun 28, 2019 at 09:27:44AM -0700, Dan Williams wrote: > > On Fri, Jun 28, 2019 at 8:39 AM Jason Gunthorpe <jgg at mellanox.com> wrote: > > > > > > On Wed, Jun 26, 2019 at 02:27:15PM +0200, Christoph Hellwig wrote: > > > > The functionality is identical to

On Fri, Jun 28, 2019 at 10:10:12AM -0700, Dan Williams wrote: > On Fri, Jun 28, 2019 at 10:08 AM Dan Williams <dan.j.williams at intel.com> wrote: > > > > On Fri, Jun 28, 2019 at 10:02 AM Jason Gunthorpe <jgg at mellanox.com> wrote: > > > > > > On Fri, Jun 28, 2019 at 09:27:44AM -0700, Dan Williams wrote: > > > > On Fri, Jun 28, 2019 at 8:39

On Wed, Jun 26, 2019 at 02:27:14PM +0200, Christoph Hellwig wrote: > Provide an internal refcounting logic if no ->ref field is provided > in the pagemap passed into devm_memremap_pages so that callers don't > have to reinvent it poorly. > > Signed-off-by: Christoph Hellwig <hch at lst.de> > --- > include/linux/memremap.h | 4 ++ > kernel/memremap.c

On Fri, Jun 28, 2019 at 11:29 AM Jason Gunthorpe <jgg at mellanox.com> wrote: > > On Fri, Jun 28, 2019 at 10:10:12AM -0700, Dan Williams wrote: > > On Fri, Jun 28, 2019 at 10:08 AM Dan Williams <dan.j.williams at intel.com> wrote: > > > > > > On Fri, Jun 28, 2019 at 10:02 AM Jason Gunthorpe <jgg at mellanox.com> wrote: > > > > > >

Hi Dan, Jérôme and Jason, below is a series that cleans up the dev_pagemap interface so that it is more easily usable, which removes the need to wrap it in hmm and thus allowing to kill a lot of code Note: this series is on top of Linux 5.2-rc6 and has some minor conflicts with the hmm tree that are easy to resolve. Diffstat summary: 34 files changed, 379 insertions(+), 1016 deletions(-) Git

On Tue 25-06-19 20:15:28, John Hubbard wrote: > On 6/19/19 12:27 PM, Jason Gunthorpe wrote: > > On Thu, Jun 13, 2019 at 06:23:04PM -0700, John Hubbard wrote: > >> On 6/13/19 5:43 PM, Ira Weiny wrote: > >>> On Thu, Jun 13, 2019 at 07:58:29PM +0000, Jason Gunthorpe wrote: > >>>> On Thu, Jun 13, 2019 at 12:53:02PM -0700, Ralph Campbell wrote: >

virtio-mem wants to allow to offline memory blocks of which some parts were unplugged, especially, to later offline and remove completely unplugged memory blocks. The important part is that PageOffline() has to remain set until the section is offline, so these pages will never get accessed (e.g., when dumping). The pages should not be handed back to the buddy (which would require clearing

Hi Dan, Jérôme and Jason, below is a series that cleans up the dev_pagemap interface so that it is more easily usable, which removes the need to wrap it in hmm and thus allowing to kill a lot of code Note: this series is on top of Linux 5.2-rc5 and has some minor conflicts with the hmm tree that are easy to resolve. Diffstat summary: 32 files changed, 361 insertions(+), 1012 deletions(-) Git

On 6/13/19 5:43 PM, Ira Weiny wrote: > On Thu, Jun 13, 2019 at 07:58:29PM +0000, Jason Gunthorpe wrote: >> On Thu, Jun 13, 2019 at 12:53:02PM -0700, Ralph Campbell wrote: >>> ... >> Hum, so the only thing this config does is short circuit here: >> >> static inline bool is_device_public_page(const struct page *page) >> { >> return

On Thu, Jun 13, 2019 at 05:22:17PM -0700, Ira Weiny wrote: > > - dev_dax->pgmap.ref = &dev_dax->ref; > > I don't think this exactly correct. pgmap.ref is a pointer to the dev_dax ref > structure. Taking it away will cause devm_memremap_pages() to fail AFAICS. > > I think you need to change struct dev_pagemap as well: Take a look at the previous patch, which

On Thu, Jun 13, 2019 at 05:43:15PM -0700, Ira Weiny wrote: > <sigh> yes but the earlier patch: > > [PATCH 03/22] mm: remove hmm_devmem_add_resource > > Removes the only place type is set to MEMORY_DEVICE_PUBLIC. > > So I think it is ok. Frankly I was wondering if we should remove the public > type altogether but conceptually it seems ok. But I don't see any