search for: mmotm

...t; On Tue, Mar 31, 2020 at 11:27:54AM -0700, Randy Dunlap wrote: >>>> On 3/30/20 6:47 PM, akpm at linux-foundation.org wrote: >>>>> The mm-of-the-moment snapshot 2020-03-30-18-46 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. U...

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 { > unsigned long flags; > struct mem_cgroup *mem_cgroup; > - struct page *page; > + /* block io tracking will use ex...

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 { > unsigned long flags; > struct mem_cgroup *mem_cgroup; > - struct page *page; > + /* block io tracking will use ex...

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 { > unsigned long flags; > struct mem_cgroup *mem_cgroup; > - struct page *page; > + /* block io tracking will use ex...

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 > in -rc5-mmotm0719. 'e16' is the Enlightenment window manager, if that matters. > > [ 93.181787] [drm:output_poll_execute] *ERROR* delayed enqueue failed 1 > [ 99.80...

[ 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>

...type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL' arch/x86/xen/mmu.c:239: warning: parameter names (without types) in function declaration Signed-off-by: Randy Dunlap <randy.dunlap at oracle.com> --- arch/x86/xen/mmu.c | 1 + 1 file changed, 1 insertion(+) --- mmotm-2009-0505-2119.orig/arch/x86/xen/mmu.c +++ mmotm-2009-0505-2119/arch/x86/xen/mmu.c @@ -42,6 +42,7 @@ #include <linux/highmem.h> #include <linux/debugfs.h> #include <linux/bug.h> +#include <linux/module.h> #include <asm/pgtable.h> #include <asm/tlbflush.h>

...type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL' arch/x86/xen/mmu.c:239: warning: parameter names (without types) in function declaration Signed-off-by: Randy Dunlap <randy.dunlap at oracle.com> --- arch/x86/xen/mmu.c | 1 + 1 file changed, 1 insertion(+) --- mmotm-2009-0505-2119.orig/arch/x86/xen/mmu.c +++ mmotm-2009-0505-2119/arch/x86/xen/mmu.c @@ -42,6 +42,7 @@ #include <linux/highmem.h> #include <linux/debugfs.h> #include <linux/bug.h> +#include <linux/module.h> #include <asm/pgtable.h> #include <asm/tlbflush.h>

...r 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]. The patched kernel builds, boots and survives some fairly heavy testing on an 8 node istanbul x86_64. Under heavy load, I do encounter a race in the somewhat optional migration cache. Currently this generates a warning and carries on, but the one migration cache entr...

...type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL' arch/x86/xen/mmu.c:239: warning: parameter names (without types) in function declaration Signed-off-by: Randy Dunlap <randy.dunlap at oracle.com> --- arch/x86/xen/mmu.c | 1 + 1 file changed, 1 insertion(+) --- mmotm-2009-0505-2119.orig/arch/x86/xen/mmu.c +++ mmotm-2009-0505-2119/arch/x86/xen/mmu.c @@ -42,6 +42,7 @@ #include <linux/highmem.h> #include <linux/debugfs.h> #include <linux/bug.h> +#include <linux/module.h> #include <asm/pgtable.h> #include <asm/tlbflush.h>

...r 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]. The patched kernel builds, boots and survives some fairly heavy testing on an 8 node istanbul x86_64. Under heavy load, I do encounter a race in the somewhat optional migration cache. Currently this generates a warning and carries on, but the one migration cache entr...

...ter crab because (page_idx / class->pages_per_zspage) was totally wrong. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > 6408: f0 0f ba 28 00 lock btsl $0x0,(%rax) <snip> > > Could you test with [zsmalloc: keep first object offset in struct page] > > in mmotm? > > sure, I can. will it help, tho? we have a race condition here I think. I guess root cause is caused by get_first_obj_offset. Please test with it. Thanks!

...ter crab because (page_idx / class->pages_per_zspage) was totally wrong. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > 6408: f0 0f ba 28 00 lock btsl $0x0,(%rax) <snip> > > Could you test with [zsmalloc: keep first object offset in struct page] > > in mmotm? > > sure, I can. will it help, tho? we have a race condition here I think. I guess root cause is caused by get_first_obj_offset. Please test with it. Thanks!

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 format-patch, please see https://stackoverflow.com/a/37406982] url: https://github.com/0day-ci/linux/com...

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 https://git-scm.com/docs/git-format-pa...

...eds this to be converted to be independent of "public" pages. > Perhaps it should be pulled out of -mm and incorporated in this > series. > > [1]: https://lore.kernel.org/lkml/20190605214922.17684-1-ira.weiny at intel.com/ Agreed and Andrew picked the first 2 versions of it, mmotm commits: 3eed114b5b6b mm-swap-fix-release_pages-when-releasing-devmap-pages-v2 9b7d8d0f572f mm/swap.c: fix release_pages() when releasing devmap pages I don't see v3 but there were no objections... Ira

...per_zspage) was totally > wrong. > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > 6408: f0 0f ba 28 00 lock btsl $0x0,(%rax) > > <snip> > > > > Could you test with [zsmalloc: keep first object offset in struct page] > > > in mmotm? > > > > sure, I can. will it help, tho? we have a race condition here I think. > > I guess root cause is caused by get_first_obj_offset. sounds reasonable. > Please test with it. this is what I'm getting with the [zsmalloc: keep first object offset in struct page] a...

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 a week. > on x86_64: ../drivers/gpu/drm/nouveau/nvkm/subdev/ltc/gp10b....

...: factor page chain functionality out zsmalloc: introduce zspage structure zsmalloc: separate free_zspage from putback_zspage zsmalloc: use freeobj for index 5. zsmalloc page migration zsmalloc: page migration support zram: use __GFP_MOVABLE for memory allocation * From v3 * rebase on mmotm-2016-04-06-20-40 * fix swap_info deadlock - Chulmin * race without page_lock - Vlastimil * no use page._mapcount for potential user-mapped page driver - Vlastimil * fix and enhance doc/description - Vlastimil * use page->mapping lower bits to represent PG_movable * make driver side...

...: factor page chain functionality out zsmalloc: introduce zspage structure zsmalloc: separate free_zspage from putback_zspage zsmalloc: use freeobj for index 5. zsmalloc page migration zsmalloc: page migration support zram: use __GFP_MOVABLE for memory allocation * From v3 * rebase on mmotm-2016-04-06-20-40 * fix swap_info deadlock - Chulmin * race without page_lock - Vlastimil * no use page._mapcount for potential user-mapped page driver - Vlastimil * fix and enhance doc/description - Vlastimil * use page->mapping lower bits to represent PG_movable * make driver side...