similar to: mmotm 2020-03-30-18-46 uploaded (VDPA + vhost)

vDPA device is a device that uses a datapath which complies with the virtio specifications with vendor specific control path. vDPA devices can be both physically located on the hardware or emulated by software. vDPA hardware devices are usually implemented through PCIE with the following types: - PF (Physical Function) - A single Physical Function - VF (Virtual Function) - Device that supports

vDPA device is a device that uses a datapath which complies with the virtio specifications with vendor specific control path. vDPA devices can be both physically located on the hardware or emulated by software. vDPA hardware devices are usually implemented through PCIE with the following types: - PF (Physical Function) - A single Physical Function - VF (Virtual Function) - Device that supports

On Wed, Jul 28, 2010 at 01:42:03AM -0400, Valdis.Kletnieks at vt.edu wrote: > On Tue, 27 Jul 2010 14:56:50 PDT, akpm at linux-foundation.org said: > > The mm-of-the-moment snapshot 2010-07-27-14-56 has been uploaded to > > > > http://userweb.kernel.org/~akpm/mmotm/ > > Hit this while the X server was on its way down during a 'shutdown -r now'. Worked fine

Hi David, I love your patch! Yet something to improve: [auto build test ERROR on next-20200909] [cannot apply to mmotm/master hnaz-linux-mm/master xen-tip/linux-next powerpc/next linus/master v5.9-rc4 v5.9-rc3 v5.9-rc2 v5.9-rc4] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in

On 1/21/20 1:29 PM, akpm at linux-foundation.org wrote: > The mm-of-the-moment snapshot 2020-01-21-13-28 has been uploaded to > > http://www.ozlabs.org/~akpm/mmotm/ > > mmotm-readme.txt says > > README for mm-of-the-moment: > > http://www.ozlabs.org/~akpm/mmotm/ > > This is a snapshot of my -mm patch queue. Uploaded at random hopefully > more than once

Hi Kamezawa-san, As you wrote before (http://lkml.org/lkml/2009/7/22/65) > To be honest, what I expected in these days for people of blockio > cgroup is like following for getting room for themselves. <<snip>> > --- mmotm-2.6.31-Jul16.orig/include/linux/page_cgroup.h > +++ mmotm-2.6.31-Jul16/include/linux/page_cgroup.h > @@ -13,7 +13,7 @@ > struct page_cgroup { >

Hi Kamezawa-san, As you wrote before (http://lkml.org/lkml/2009/7/22/65) > To be honest, what I expected in these days for people of blockio > cgroup is like following for getting room for themselves. <<snip>> > --- mmotm-2.6.31-Jul16.orig/include/linux/page_cgroup.h > +++ mmotm-2.6.31-Jul16/include/linux/page_cgroup.h > @@ -13,7 +13,7 @@ > struct page_cgroup { >

Hi Kamezawa-san, As you wrote before (http://lkml.org/lkml/2009/7/22/65) > To be honest, what I expected in these days for people of blockio > cgroup is like following for getting room for themselves. <<snip>> > --- mmotm-2.6.31-Jul16.orig/include/linux/page_cgroup.h > +++ mmotm-2.6.31-Jul16/include/linux/page_cgroup.h > @@ -13,7 +13,7 @@ > struct page_cgroup { >

From: Randy Dunlap <randy.dunlap at oracle.com> mmu.c needs to #include module.h to prevent these warnings: arch/x86/xen/mmu.c:239: warning: data definition has no type or storage class arch/x86/xen/mmu.c:239: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL' arch/x86/xen/mmu.c:239: warning: parameter names (without types) in function declaration

From: Randy Dunlap <randy.dunlap at oracle.com> mmu.c needs to #include module.h to prevent these warnings: arch/x86/xen/mmu.c:239: warning: data definition has no type or storage class arch/x86/xen/mmu.c:239: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL' arch/x86/xen/mmu.c:239: warning: parameter names (without types) in function declaration

From: Randy Dunlap <randy.dunlap at oracle.com> mmu.c needs to #include module.h to prevent these warnings: arch/x86/xen/mmu.c:239: warning: data definition has no type or storage class arch/x86/xen/mmu.c:239: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL' arch/x86/xen/mmu.c:239: warning: parameter names (without types) in function declaration

At last weeks' LPC, there was some interest in my patches for Auto/Lazy Migration to improve locality and possibly performance of unpinned guest VMs on a NUMA platform. As a result of these conversations I have reposted the patches [4 series, ~40 patches] as RFCs to the linux-numa list. Links to threads given below. I have rebased the patches atop 3Nov10 mmotm series [2.6.36 + 3nov mmotm].

At last weeks' LPC, there was some interest in my patches for Auto/Lazy Migration to improve locality and possibly performance of unpinned guest VMs on a NUMA platform. As a result of these conversations I have reposted the patches [4 series, ~40 patches] as RFCs to the linux-numa list. Links to threads given below. I have rebased the patches atop 3Nov10 mmotm series [2.6.36 + 3nov mmotm].

On Mon, Feb 10, 2020 at 11:56:06AM +0800, Jason Wang wrote: > +/** > + * vdpa_register_device - register a vDPA device > + * Callers must have a succeed call of vdpa_init_device() before. > + * @vdev: the vdpa device to be registered to vDPA bus > + * > + * Returns an error when fail to add to vDPA bus > + */ > +int vdpa_register_device(struct vdpa_device *vdev) > +{

On Mon, Feb 10, 2020 at 11:56:06AM +0800, Jason Wang wrote: > +/** > + * vdpa_register_device - register a vDPA device > + * Callers must have a succeed call of vdpa_init_device() before. > + * @vdev: the vdpa device to be registered to vDPA bus > + * > + * Returns an error when fail to add to vDPA bus > + */ > +int vdpa_register_device(struct vdpa_device *vdev) > +{

On 2020/2/11 ??9:47, Jason Gunthorpe wrote: > On Mon, Feb 10, 2020 at 11:56:06AM +0800, Jason Wang wrote: >> +/** >> + * vdpa_register_device - register a vDPA device >> + * Callers must have a succeed call of vdpa_init_device() before. >> + * @vdev: the vdpa device to be registered to vDPA bus >> + * >> + * Returns an error when fail to add to vDPA bus

On 2020/7/16 ??7:23, Zhu Lingshan wrote: > This commit implements IRQ offloading helpers Let's say "vq irq allocate/free helpers" here. > in vDPA core by > introducing two couple of functions: > > vdpa_alloc_vq_irq() and vdpa_free_vq_irq(): request irq and free > irq, will setup irq offloading. > > vdpa_setup_irq() and vdpa_unsetup_irq(): supportive

Hi David, I love your patch! Yet something to improve: [auto build test ERROR on pm/linux-next] [also build test ERROR on linus/master v5.6-rc4 next-20200302] [cannot apply to linux/master mmotm/master] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system. BTW, we also suggest to use '--base' option to specify the base tree in git

On 2020/7/12 ??10:49, Zhu Lingshan wrote: > This commit implements IRQ offloading helpers in vDPA core by > introducing two couple of functions: > > vdpa_alloc_vq_irq() and vdpa_free_vq_irq(): request irq and free > irq, will setup irq offloading if irq_bypass is enabled. > > vdpa_setup_irq() and vdpa_unsetup_irq(): supportive functions, > will call vhost_vdpa helpers. >

On Wed, Jun 26, 2019 at 09:00:47AM -0700, Dan Williams 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> > >