[PATCH 01/31] huge tmpfs: prepare counts in meminfo, vmstat and SysRq-m

in fs/proc/meminfo.c and drivers/base/node.c: the shorter names help. Clarify a comment in page_remove_rmap() to refer to "hugetlbfs pages" rather than hugepages generally. I left arch/tile/mm/pgtable.c's show_mem() unchanged: tile does not HAVE_ARCH_TRANSPARENT_HUGEPAGE. Signed-off-by: Hu

[PATCH 00/31] huge tmpfs: THPagecache implemented by teams

Here is my "huge tmpfs" implementation of Transparent Huge Pagecache, rebased to v4.6-rc2 plus the "mm: easy preliminaries to THPagecache" series. The design is just the same as before, when I posted against v3.19: using a team of pagecache pages placed within a huge-order extent, instead of

[PATCH 00/31] huge tmpfs: THPagecache implemented by teams

Here is my "huge tmpfs" implementation of Transparent Huge Pagecache, rebased to v4.6-rc2 plus the "mm: easy preliminaries to THPagecache" series. The design is just the same as before, when I posted against v3.19: using a team of pagecache pages placed within a huge-order extent, instead of

[PATCH 10/10] arch: fix has_transparent_hugepage()

it's called). Signed-off-by: Hugh Dickins <hu...@google.com> --- arch/arc/include/asm/hugepage.h |2 - arch/arm/include/asm/pgtable-3level.h|5 arch/arm64/include/asm/pgtable.h |5 arch/mips/include/asm/pgtable.h |1 arc

[PATCH 10/10] arch: fix has_transparent_hugepage()

it's called). Signed-off-by: Hugh Dickins --- arch/arc/include/asm/hugepage.h |2 - arch/arm/include/asm/pgtable-3level.h|5 arch/arm64/include/asm/pgtable.h |5 arch/mips/include/asm/pgtable.h |1 arch/mips/mm/tlb-r4k.c

[PATCH 09/10] huge pagecache: mmap_sem is unlocked when truncation splits pmd

done. And let's get this in, without waiting for any particular huge pagecache implementation to reach the tree. Signed-off-by: Hugh Dickins <hu...@google.com> --- mm/memory.c | 11 ++- 1 file changed, 2 insertions(+), 9 deletions(-) --- a/mm/memory.c +++ b/mm/memory.c @@ -1182,1

[PATCH 09/10] huge pagecache: mmap_sem is unlocked when truncation splits pmd

done. And let's get this in, without waiting for any particular huge pagecache implementation to reach the tree. Signed-off-by: Hugh Dickins --- mm/memory.c | 11 ++- 1 file changed, 2 insertions(+), 9 deletions(-) --- a/mm/memory.c +++ b/mm/memory.c @@ -1182,15 +1182,8 @@ static

[PATCH 07/10] huge mm: move_huge_pmd does not need new_vma

Remove move_huge_pmd()'s redundant new_vma arg: all it was used for was a VM_NOHUGEPAGE check on new_vma flags, but the new_vma is cloned from the old vma, so a trans_huge_pmd in the new_vma will be as acceptable as it was in the old vma, alignment and size permitting. Signed-off-by: Hugh Dickins

[PATCH 07/10] huge mm: move_huge_pmd does not need new_vma

Remove move_huge_pmd()'s redundant new_vma arg: all it was used for was a VM_NOHUGEPAGE check on new_vma flags, but the new_vma is cloned from the old vma, so a trans_huge_pmd in the new_vma will be as acceptable as it was in the old vma, alignment and size permitting. Signed-off-by: Hugh Dickins

[PATCH 08/10] huge pagecache: extend mremap pmd rmap lockout to files

() and move_page_tables(), and delete the VM_BUG_ON_VMA which rejected vm_file and required anon_vma. Signed-off-by: Hugh Dickins <hu...@google.com> --- mm/mremap.c | 42 ++ 1 file changed, 22 insertions(+), 20 deletions(-) --- a/mm/mremap.c ++

[PATCH 08/10] huge pagecache: extend mremap pmd rmap lockout to files

() and move_page_tables(), and delete the VM_BUG_ON_VMA which rejected vm_file and required anon_vma. Signed-off-by: Hugh Dickins --- mm/mremap.c | 42 ++ 1 file changed, 22 insertions(+), 20 deletions(-) --- a/mm/mremap.c +++ b/mm/mremap.c @@ -70,6

[PATCH 06/10] mm: /proc/sys/vm/stat_refresh to force vmstat update

or the moment by just ignoring the anomaly on those. Signed-off-by: Hugh Dickins <hu...@google.com> --- Documentation/sysctl/vm.txt | 14 include/linux/vmstat.h |4 ++ kernel/sysctl.c |7 mm/vmstat.c | 58 ++

[PATCH 06/10] mm: /proc/sys/vm/stat_refresh to force vmstat update

or the moment by just ignoring the anomaly on those. Signed-off-by: Hugh Dickins --- Documentation/sysctl/vm.txt | 14 include/linux/vmstat.h |4 ++ kernel/sysctl.c |7 mm/vmstat.c | 58 ++

[PATCH 05/10] tmpfs: mem_cgroup charge fault to vm_mm not current mm

way: change the common shmem_getpage() wrapper to hide fault_mm and fault_type as well as gfp. Signed-off-by: Andres Lagar-Cavilla <andre...@google.com> Signed-off-by: Hugh Dickins <hu...@google.com> --- mm/shmem.c | 61 --- 1 fil

[PATCH 05/10] tmpfs: mem_cgroup charge fault to vm_mm not current mm

common shmem_getpage() wrapper to hide fault_mm and fault_type as well as gfp. Signed-off-by: Andres Lagar-Cavilla Signed-off-by: Hugh Dickins --- mm/shmem.c | 61 --- 1 file changed, 34 insertions(+), 27 deletions(-) --- a/mm/shmem.c +++ b/mm/s

[PATCH 04/10] tmpfs: preliminary minor tidyups

ogged it back to reality. Signed-off-by: Hugh Dickins <hu...@google.com> --- include/linux/mempolicy.h |6 +++ mm/shmem.c| 69 +--- 2 files changed, 32 insertions(+), 43 deletions(-) --- a/include/linux/mempolicy.h +++ b/include/linux/mempolicy.

[PATCH 04/10] tmpfs: preliminary minor tidyups

ogged it back to reality. Signed-off-by: Hugh Dickins --- include/linux/mempolicy.h |6 +++ mm/shmem.c| 69 +--- 2 files changed, 32 insertions(+), 43 deletions(-) --- a/include/linux/mempolicy.h +++ b/include/linux/mempolicy.h @@ -228,6 +228,12 @@

[PATCH 03/10] mm: use __SetPageSwapBacked and dont ClearPageSwapBacked

or further __SetPageFlags in other places, but SwapBacked is the one I'm interested in at the moment. Signed-off-by: Hugh Dickins <hu...@google.com> --- Sorry, Mel did give Reviewed-by: Mel Gorman <mgor...@suse.de> a year ago, but the kernel has moved on since then, so it feels slightly ruder to carr

[PATCH 03/10] mm: use __SetPageSwapBacked and dont ClearPageSwapBacked

or further __SetPageFlags in other places, but SwapBacked is the one I'm interested in at the moment. Signed-off-by: Hugh Dickins --- Sorry, Mel did give Reviewed-by: Mel Gorman a year ago, but the kernel has moved on since then, so it feels slightly ruder to carry that forward without asking, than to ask a

[PATCH 02/10] mm: update_lru_size do the __mod_zone_page_state

is not peculiar to mem_cgroups: so better use the name update_lru_size, calls mem_cgroup_update_lru_size when CONFIG_MEMCG. Signed-off-by: Hugh Dickins <hu...@google.com> --- include/linux/memcontrol.h |6 -- include/linux/mm_inline.h | 24 ++-- mm/memcontrol.c

[PATCH 02/10] mm: update_lru_size do the __mod_zone_page_state

is not peculiar to mem_cgroups: so better use the name update_lru_size, calls mem_cgroup_update_lru_size when CONFIG_MEMCG. Signed-off-by: Hugh Dickins --- include/linux/memcontrol.h |6 -- include/linux/mm_inline.h | 24 ++-- mm/memcontrol.c|2 ++ mm/vmscan.c

[PATCH 01/10] mm: update_lru_size warn and reset bad lru_size

. But the particular bug which suggested this change was mine alone, and since fixed. Make it a WARN_ONCE: the first occurrence is the most informative, a flurry may follow, yet even when rate-limited little more is learnt. Signed-off-by: Hugh Dickins <hu...@google.com> --- include/linux/mm_in

[PATCH 01/10] mm: update_lru_size warn and reset bad lru_size

. But the particular bug which suggested this change was mine alone, and since fixed. Make it a WARN_ONCE: the first occurrence is the most informative, a flurry may follow, yet even when rate-limited little more is learnt. Signed-off-by: Hugh Dickins --- include/linux/mm_inline.h |2 +- mm

[PATCH 00/10] mm: easy preliminaries to THPagecache

-by: Hugh Dickins <hu...@google.com> --- mm/filemap.c |4 ++-- mm/memory.c |6 +++--- mm/rmap.c|2 +- mm/shmem.c | 18 +- 4 files changed, 15 insertions(+), 15 deletions(-) --- a/mm/filemap.c +++ b/mm/filemap.c @@ -2178,8 +2178,8 @@

[PATCH 00/10] mm: easy preliminaries to THPagecache

-by: Hugh Dickins --- mm/filemap.c |4 ++-- mm/memory.c |6 +++--- mm/rmap.c|2 +- mm/shmem.c | 18 +- 4 files changed, 15 insertions(+), 15 deletions(-) --- a/mm/filemap.c +++ b/mm/filemap.c @@ -2178,8 +2178,8 @@ repeat: if (page->mapp

Re: 4.5 shmem lockdep/out-of-bound/list corruption disaster

On Mon, 28 Mar 2016, Dave Jones wrote: > I hit this a few days ago. I'm not 100% what kernel it was running, > but I'm pretty sure it was a post 4.5 kernel from this merge window. Thanks for the report. All consistent with shmem_fallocate() somehow getting through its wake_up_all() without

Re: 4.5 shmem lockdep/out-of-bound/list corruption disaster

On Mon, 28 Mar 2016, Dave Jones wrote: > I hit this a few days ago. I'm not 100% what kernel it was running, > but I'm pretty sure it was a post 4.5 kernel from this merge window. Thanks for the report. All consistent with shmem_fallocate() somehow getting through its wake_up_all() without

Re: [PATCHv4 00/25] THP-enabled tmpfs/shmem

On Mon, 28 Mar 2016, Kirill A. Shutemov wrote: > > I think I found it. I have refcounting screwed up in faultaround. > > This should fix the problem: Yes, this fixes it for me - thanks. Hugh > > diff --git a/mm/filemap.c b/mm/filemap.c > index 94c097ec08e7..1325bb4568d1 100644 > ---

Re: [PATCHv4 00/25] THP-enabled tmpfs/shmem

On Mon, 28 Mar 2016, Kirill A. Shutemov wrote: > > I think I found it. I have refcounting screwed up in faultaround. > > This should fix the problem: Yes, this fixes it for me - thanks. Hugh > > diff --git a/mm/filemap.c b/mm/filemap.c > index 94c097ec08e7..1325bb4568d1 100644 > ---

Re: [PATCHv4 00/25] THP-enabled tmpfs/shmem

On Fri, 25 Mar 2016, Kirill A. Shutemov wrote: > On Thu, Mar 24, 2016 at 12:08:55PM -0700, Hugh Dickins wrote: > > On Thu, 24 Mar 2016, Kirill A. Shutemov wrote: > > > On Wed, Mar 23, 2016 at 01:09:05PM -0700, Hugh Dickins wrote: > > > > The small files thing formed m

Re: [PATCHv4 00/25] THP-enabled tmpfs/shmem

On Fri, 25 Mar 2016, Kirill A. Shutemov wrote: > On Thu, Mar 24, 2016 at 12:08:55PM -0700, Hugh Dickins wrote: > > On Thu, 24 Mar 2016, Kirill A. Shutemov wrote: > > > On Wed, Mar 23, 2016 at 01:09:05PM -0700, Hugh Dickins wrote: > > > > The small files thing formed m

Re: [PATCHv4 00/25] THP-enabled tmpfs/shmem

On Thu, 24 Mar 2016, Kirill A. Shutemov wrote: > On Wed, Mar 23, 2016 at 01:09:05PM -0700, Hugh Dickins wrote: > > The small files thing formed my first impression. My second > > impression was similar, when I tried mmap(NULL, size_of_RAM, > > PROT_READ|PROT_WRITE, MAP_ANONYM

Re: [PATCHv4 00/25] THP-enabled tmpfs/shmem

On Thu, 24 Mar 2016, Kirill A. Shutemov wrote: > On Wed, Mar 23, 2016 at 01:09:05PM -0700, Hugh Dickins wrote: > > The small files thing formed my first impression. My second > > impression was similar, when I tried mmap(NULL, size_of_RAM, > > PROT_READ|PROT_WRITE, MAP_ANONYM

Re: [PATCHv4 00/25] THP-enabled tmpfs/shmem

On Sat, 12 Mar 2016, Kirill A. Shutemov wrote: > Here is an updated version of huge pages support implementation in > tmpfs/shmem. > > All known issues has been fixed. I'll continue with validation. > I will also send follow up patch with documentation update. > > Hugh, I would be glad to hear

Re: [PATCHv4 00/25] THP-enabled tmpfs/shmem

On Sat, 12 Mar 2016, Kirill A. Shutemov wrote: > Here is an updated version of huge pages support implementation in > tmpfs/shmem. > > All known issues has been fixed. I'll continue with validation. > I will also send follow up patch with documentation update. > > Hugh, I would be glad to hear

Re: [PATCH 2/9] mm, oom: introduce oom reaper

;mho...@suse.com> > Cc: Andrea Argangeli <and...@kernel.org> > Acked-by: David Rientjes <rient...@google.com> > Cc: Hugh Dickins <hu...@google.com> > Cc: Johannes Weiner <han...@cmpxchg.org> > Cc: Mel Gorman <mgor...@suse.de> > Cc: Oleg Nesterov <

Re: [PATCH 2/9] mm, oom: introduce oom reaper

the reclaim to cull the > page back and mlock it again. > > munlock_vma_pages_all is also safe to be called from the oom reaper > context because it doesn't sit on any locks but mmap_sem (for read). > > Signed-off-by: Michal Hocko > Cc: Andrea Argangeli > Acked-by: David Rie

Re: [PATCH 01/71] arc: get rid of PAGE_CACHE_* and page_cache_{get,release} macros

On Sun, 20 Mar 2016, Linus Torvalds wrote: > On Sun, Mar 20, 2016 at 12:34 PM, Kirill A. Shutemov > wrote: > > > > Hm. Okay. Re-split this way would take some time. I'll post updated > > patchset tomorrow. > > Oh, I was assuming this was automated with coccinelle

Re: [PATCH 01/71] arc: get rid of PAGE_CACHE_* and page_cache_{get,release} macros

On Sun, 20 Mar 2016, Linus Torvalds wrote: > On Sun, Mar 20, 2016 at 12:34 PM, Kirill A. Shutemov > wrote: > > > > Hm. Okay. Re-split this way would take some time. I'll post updated > > patchset tomorrow. > > Oh, I was assuming this was automated with coccinelle or at least some > simple shell

Re: [PATCH 3/3] mm, oom: protect !costly allocations some more

On Fri, 11 Mar 2016, Michal Hocko wrote: > On Fri 11-03-16 04:17:30, Hugh Dickins wrote: > > On Wed, 9 Mar 2016, Michal Hocko wrote: > > > Joonsoo has pointed out that this attempt is still not sufficient > > > becasuse we might have invoked only a single compaction

Re: [PATCH 3/3] mm, oom: protect !costly allocations some more

On Fri, 11 Mar 2016, Michal Hocko wrote: > On Fri 11-03-16 04:17:30, Hugh Dickins wrote: > > On Wed, 9 Mar 2016, Michal Hocko wrote: > > > Joonsoo has pointed out that this attempt is still not sufficient > > > becasuse we might have invoked only a single compaction

Re: [PATCH 3/3] mm, oom: protect !costly allocations some more

On Wed, 9 Mar 2016, Michal Hocko wrote: > Joonsoo has pointed out that this attempt is still not sufficient > becasuse we might have invoked only a single compaction round which > is might be not enough. I fully agree with that. Here is my take on > that. It is again based on the number of retries

Re: [PATCH 3/3] mm, oom: protect !costly allocations some more

On Wed, 9 Mar 2016, Michal Hocko wrote: > Joonsoo has pointed out that this attempt is still not sufficient > becasuse we might have invoked only a single compaction round which > is might be not enough. I fully agree with that. Here is my take on > that. It is again based on the number of retries

Re: [PATCH 2/5] oom reaper: handle mlocked pages

On Tue, 8 Mar 2016, Michal Hocko wrote: > On Mon 29-02-16 14:41:39, Michal Hocko wrote: > > On Sun 28-02-16 19:19:11, Hugh Dickins wrote: > > > On Tue, 23 Feb 2016, Michal Hocko wrote: > > > > On Mon 22-02-16 17:36:07, David Rientjes wrote: > > >

Re: [PATCH 2/5] oom reaper: handle mlocked pages

On Tue, 8 Mar 2016, Michal Hocko wrote: > On Mon 29-02-16 14:41:39, Michal Hocko wrote: > > On Sun 28-02-16 19:19:11, Hugh Dickins wrote: > > > On Tue, 23 Feb 2016, Michal Hocko wrote: > > > > On Mon 22-02-16 17:36:07, David Rientjes wrote: > > >

Re: [PATCH] mm, oom: protect !costly allocations some more (was: Re: [PATCH 0/3] OOM detection rework v4)

On Mon, 7 Mar 2016, Michal Hocko wrote: > On Mon 29-02-16 22:02:13, Michal Hocko wrote: > > Andrew, > > could you queue this one as well, please? This is more a band aid than a > > real solution which I will be working on as soon as I am able to > > reproduce the issue but the patch should help to

Re: [PATCH] mm, oom: protect !costly allocations some more (was: Re: [PATCH 0/3] OOM detection rework v4)

On Mon, 7 Mar 2016, Michal Hocko wrote: > On Mon 29-02-16 22:02:13, Michal Hocko wrote: > > Andrew, > > could you queue this one as well, please? This is more a band aid than a > > real solution which I will be working on as soon as I am able to > > reproduce the issue but the patch should help to

Re: THP-enabled filesystem vs. FALLOC_FL_PUNCH_HOLE

On Fri, 4 Mar 2016, Dave Hansen wrote: > On 03/04/2016 03:26 AM, Kirill A. Shutemov wrote: > > On Thu, Mar 03, 2016 at 07:51:50PM +0300, Kirill A. Shutemov wrote: > >> Truncate and punch hole that only cover part of THP range is implemented > >> by zero out this part of THP. > >> > >> This have

Re: THP-enabled filesystem vs. FALLOC_FL_PUNCH_HOLE

On Fri, 4 Mar 2016, Dave Hansen wrote: > On 03/04/2016 03:26 AM, Kirill A. Shutemov wrote: > > On Thu, Mar 03, 2016 at 07:51:50PM +0300, Kirill A. Shutemov wrote: > >> Truncate and punch hole that only cover part of THP range is implemented > >> by zero out this part of THP. > >> > >> This have

Re: [PATCH 0/3] OOM detection rework v4

On Thu, 3 Mar 2016, Michal Hocko wrote: > On Thu 03-03-16 01:54:43, Hugh Dickins wrote: > > On Tue, 1 Mar 2016, Michal Hocko wrote: > [...] > > > So I have tried the following: > > > diff --git a/mm/compaction.c b/mm/compaction.c > > > index 4d99e1f50

Re: [PATCH 0/3] OOM detection rework v4

On Thu, 3 Mar 2016, Michal Hocko wrote: > On Thu 03-03-16 01:54:43, Hugh Dickins wrote: > > On Tue, 1 Mar 2016, Michal Hocko wrote: > [...] > > > So I have tried the following: > > > diff --git a/mm/compaction.c b/mm/compaction.c > > > index 4d99e1f50

Re: [PATCH 0/3] OOM detection rework v4

On Tue, 1 Mar 2016, Michal Hocko wrote: > [Adding Vlastimil and Joonsoo for compaction related things - this was a > large thread but the more interesting part starts with > http://lkml.kernel.org/r/alpine.LSU.2.11.1602241832160.15564@eggly.anvils] > > On Mon 29-02-16 23:29:06, Hug

Re: [PATCH 0/3] OOM detection rework v4

On Tue, 1 Mar 2016, Michal Hocko wrote: > [Adding Vlastimil and Joonsoo for compaction related things - this was a > large thread but the more interesting part starts with > http://lkml.kernel.org/r/alpine.LSU.2.11.1602241832160.15564@eggly.anvils] > > On Mon 29-02-16 23:29:06, Hug

Re: [PATCH 0/3] OOM detection rework v4

On Mon, 29 Feb 2016, Michal Hocko wrote: > On Wed 24-02-16 19:47:06, Hugh Dickins wrote: > [...] > > Boot with mem=1G (or boot your usual way, and do something to occupy > > most of the memory: I think /proc/sys/vm/nr_hugepages provides a great > > way to gobble up most of

Re: [PATCH 0/3] OOM detection rework v4

On Mon, 29 Feb 2016, Michal Hocko wrote: > On Wed 24-02-16 19:47:06, Hugh Dickins wrote: > [...] > > Boot with mem=1G (or boot your usual way, and do something to occupy > > most of the memory: I think /proc/sys/vm/nr_hugepages provides a great > > way to gobble up most of

[PATCH] mm: __delete_from_page_cache show Bad page if mapped

(rather than truncated), it won't have any vmas left, so it's safe(ish) to assume that the raised mapcount is erroneous, and we can discount it from page_count to avoid leaking the page (I'm less worried by leaking the occasional 4kB, than losing a potential 2MB page with each 4kB page leaked). Signed-o

[PATCH] mm: __delete_from_page_cache show Bad page if mapped

(rather than truncated), it won't have any vmas left, so it's safe(ish) to assume that the raised mapcount is erroneous, and we can discount it from page_count to avoid leaking the page (I'm less worried by leaking the occasional 4kB, than losing a potential 2MB page with each 4kB page leaked). Signed-off-

Re: [PATCH] mm: __delete_from_page_cache WARN_ON(page_mapped)

On Mon, 29 Feb 2016, Kirill A. Shutemov wrote: > On Sun, Feb 28, 2016 at 08:49:10PM -0800, Hugh Dickins wrote: > > Commit e1534ae95004 ("mm: differentiate page_mapped() from page_mapcount() > > for compound pages") changed the famous BUG_ON(page_mapped(page)) in >

Re: [PATCH] mm: __delete_from_page_cache WARN_ON(page_mapped)

On Mon, 29 Feb 2016, Kirill A. Shutemov wrote: > On Sun, Feb 28, 2016 at 08:49:10PM -0800, Hugh Dickins wrote: > > Commit e1534ae95004 ("mm: differentiate page_mapped() from page_mapcount() > > for compound pages") changed the famous BUG_ON(page_mapped(page)) in >

[PATCH] mm: __delete_from_page_cache WARN_ON(page_mapped)

vmas left, so it's safe(ish) to assume that the raised mapcount is erroneous, and we can discount it from page_count to avoid leaking the page (I'm less worried by leaking the occasional 4kB, than losing a potential 2MB page with each 4kB page leaked). Signed-off-by: Hugh Dickins <hu...@google.

[PATCH] mm: __delete_from_page_cache WARN_ON(page_mapped)

vmas left, so it's safe(ish) to assume that the raised mapcount is erroneous, and we can discount it from page_count to avoid leaking the page (I'm less worried by leaking the occasional 4kB, than losing a potential 2MB page with each 4kB page leaked). Signed-off-by: Hugh Dickins --- I think t

Re: [PATCH 2/5] oom reaper: handle mlocked pages

On Tue, 23 Feb 2016, Michal Hocko wrote: > On Mon 22-02-16 17:36:07, David Rientjes wrote: > > > > Are we concerned about munlock_vma_pages_all() taking lock_page() and > > perhaps stalling forever, the same way it would stall in exit_mmap() for > > VM_LOCKED vmas, if another thread has locked

Re: [PATCH 2/5] oom reaper: handle mlocked pages

On Tue, 23 Feb 2016, Michal Hocko wrote: > On Mon 22-02-16 17:36:07, David Rientjes wrote: > > > > Are we concerned about munlock_vma_pages_all() taking lock_page() and > > perhaps stalling forever, the same way it would stall in exit_mmap() for > > VM_LOCKED vmas, if another thread has locked

Re: [RFC PATCH] proc: do not include shmem and driver pages in /proc/meminfo::Cached

On Fri, 19 Feb 2016, Andrew Morton wrote: > On Fri, 19 Feb 2016 09:40:45 +0300 Konstantin Khlebnikov > wrote: > > > >> What are your thoughts on this? > > > > > > My thoughts are NAK. A misleading stat is not so bad as a > > > misleading stat whose meaning we change in some

Re: [RFC PATCH] proc: do not include shmem and driver pages in /proc/meminfo::Cached

On Fri, 19 Feb 2016, Andrew Morton wrote: > On Fri, 19 Feb 2016 09:40:45 +0300 Konstantin Khlebnikov > wrote: > > > >> What are your thoughts on this? > > > > > > My thoughts are NAK. A misleading stat is not so bad as a > > > misleading stat whose meaning we change in some random kernel. > >

Re: [RFC PATCH] proc: do not include shmem and driver pages in /proc/meminfo::Cached

On Fri, 19 Feb 2016, Konstantin Khlebnikov wrote: > On Fri, Feb 19, 2016 at 1:57 AM, Hugh Dickins <hu...@google.com> wrote: > > On Thu, 18 Feb 2016, Johannes Weiner wrote: > > > >> Even before we added MemAvailable, users knew that page cache is > >> easily

Re: [RFC PATCH] proc: do not include shmem and driver pages in /proc/meminfo::Cached

On Fri, 19 Feb 2016, Konstantin Khlebnikov wrote: > On Fri, Feb 19, 2016 at 1:57 AM, Hugh Dickins wrote: > > On Thu, 18 Feb 2016, Johannes Weiner wrote: > > > >> Even before we added MemAvailable, users knew that page cache is > >> easily convertible to free

Re: [PATCH 1/3] mm: migrate: do not touch page->mem_cgroup of live pages

On Thu, 4 Feb 2016, Johannes Weiner wrote: > On Wed, Feb 03, 2016 at 05:39:08PM -0800, Hugh Dickins wrote: > > > And (even more off-topic), I'm slightly sad to see that the lrucare > > arg which mem_cgroup_migrate() used to have (before I renamed it and > > you rename

Re: [PATCH 1/3] mm: migrate: do not touch page->mem_cgroup of live pages

On Thu, 4 Feb 2016, Johannes Weiner wrote: > On Wed, Feb 03, 2016 at 05:39:08PM -0800, Hugh Dickins wrote: > > > And (even more off-topic), I'm slightly sad to see that the lrucare > > arg which mem_cgroup_migrate() used to have (before I renamed it and > > you rename

Re: [PATCH 0/3] OOM detection rework v4

On Thu, 25 Feb 2016, Michal Hocko wrote: > On Wed 24-02-16 19:47:06, Hugh Dickins wrote: > [...] > > Boot with mem=1G (or boot your usual way, and do something to occupy > > most of the memory: I think /proc/sys/vm/nr_hugepages provides a great > > way to gobble up most of

Re: [PATCH 0/3] OOM detection rework v4

On Thu, 25 Feb 2016, Michal Hocko wrote: > On Wed 24-02-16 19:47:06, Hugh Dickins wrote: > [...] > > Boot with mem=1G (or boot your usual way, and do something to occupy > > most of the memory: I think /proc/sys/vm/nr_hugepages provides a great > > way to gobble up most of

Re: [RFC v5 0/3] mm: make swapin readahead to gain more thp performance

On Fri, 26 Feb 2016, Ebru Akagunduz wrote: > in Thu, Feb 25, 2016 at 05:35:50PM -0500, Rik van Riel wrote: > > On Wed, 2016-02-24 at 23:36 -0800, Hugh Dickins wrote: > > >  > > > Doesn't this imply that __collapse_huge_page_swapin() will initiate > > > all &

Re: [RFC v5 0/3] mm: make swapin readahead to gain more thp performance

On Fri, 26 Feb 2016, Ebru Akagunduz wrote: > in Thu, Feb 25, 2016 at 05:35:50PM -0500, Rik van Riel wrote: > > On Wed, 2016-02-24 at 23:36 -0800, Hugh Dickins wrote: > > >  > > > Doesn't this imply that __collapse_huge_page_swapin() will initiate > > > all &

Re: [RFC v5 0/3] mm: make swapin readahead to gain more thp performance

On Mon, 14 Sep 2015, Andrew Morton wrote: > On Mon, 14 Sep 2015 22:31:42 +0300 Ebru Akagunduz > wrote: > > > This patch series makes swapin readahead up to a > > certain number to gain more thp performance and adds > > tracepoint for khugepaged_scan_pmd,

Re: [RFC v5 0/3] mm: make swapin readahead to gain more thp performance

On Mon, 14 Sep 2015, Andrew Morton wrote: > On Mon, 14 Sep 2015 22:31:42 +0300 Ebru Akagunduz > wrote: > > > This patch series makes swapin readahead up to a > > certain number to gain more thp performance and adds > > tracepoint for khugepaged_scan_pmd, collapse_huge_page, > >

Re: [PATCH 0/3] OOM detection rework v4

On Wed, 3 Feb 2016, Michal Hocko wrote: > Hi, > this thread went mostly quite. Are all the main concerns clarified? > Are there any new concerns? Are there any objections to targeting > this for the next merge window? Sorry to say at this late date, but I do have one concern: hopefully you can

Re: [PATCH 0/3] OOM detection rework v4

On Wed, 3 Feb 2016, Michal Hocko wrote: > Hi, > this thread went mostly quite. Are all the main concerns clarified? > Are there any new concerns? Are there any objections to targeting > this for the next merge window? Sorry to say at this late date, but I do have one concern: hopefully you can

Re: [RFC PATCH] proc: do not include shmem and driver pages in /proc/meminfo::Cached

On Thu, 18 Feb 2016, Johannes Weiner wrote: > Even before we added MemAvailable, users knew that page cache is > easily convertible to free memory on pressure, and estimated their > "available" memory by looking at the sum of MemFree, Cached, Buffers. > However, "Cached" is calculated using

Re: [RFC PATCH] proc: do not include shmem and driver pages in /proc/meminfo::Cached

On Thu, 18 Feb 2016, Johannes Weiner wrote: > Even before we added MemAvailable, users knew that page cache is > easily convertible to free memory on pressure, and estimated their > "available" memory by looking at the sum of MemFree, Cached, Buffers. > However, "Cached" is calculated using

Re: [PATCH 1/3] mm: migrate: do not touch page->mem_cgroup of live pages

On Wed, 3 Feb 2016, Johannes Weiner wrote: > CCing Hugh and Greg, they have worked on the memcg migration code most > recently. AFAIK the only reason newpage->mem_cgroup had to be set up > that early in migration was because of the way dirty accounting used > to work. But Hugh took memcg out of

Re: [PATCH 1/3] mm: migrate: do not touch page->mem_cgroup of live pages

On Wed, 3 Feb 2016, Johannes Weiner wrote: > CCing Hugh and Greg, they have worked on the memcg migration code most > recently. AFAIK the only reason newpage->mem_cgroup had to be set up > that early in migration was because of the way dirty accounting used > to work. But Hugh took memcg out of

Re: 4.5-rc1: mm/gup.c warning when writing to /proc/self/mem

and become even more obscure: delete it. Reported-by: Dave Jones Suggested-by: Kirill A. Shutemov Signed-off-by: Hugh Dickins --- mm/gup.c|4 +--- mm/memory.c |5 - 2 files changed, 1 insertion(+), 8 deletions(-) --- 4.5-rc1/mm/gup.c2016-01-24 14:54:58.031544001 -0800 +++ linux/

Re: 4.5-rc1: mm/gup.c warning when writing to /proc/self/mem

nd become even more obscure: delete it. Reported-by: Dave Jones <da...@codemonkey.org.uk> Suggested-by: Kirill A. Shutemov <kir...@shutemov.name> Signed-off-by: Hugh Dickins <hu...@google.com> --- mm/gup.c|4 +--- mm/memory.c |5 - 2 files changed, 1 insertion(+),

Re: [PATCH v4] futex: Remove requirement for lock_page in get_futex_key

On Fri, 29 Jan 2016, Davidlohr Bueso wrote: > On Wed, 27 Jan 2016, Hugh Dickins wrote: > > > > + * > > > + * The RCU read lock is taken as the inode is finally freed > > > + * under RCU. If the mapping still matches expectations then >

Re: [PATCH v4] futex: Remove requirement for lock_page in get_futex_key

On Fri, 29 Jan 2016, Davidlohr Bueso wrote: > On Wed, 27 Jan 2016, Hugh Dickins wrote: > > > > + * > > > + * The RCU read lock is taken as the inode is finally freed > > > + * under RCU. If the mapping still matches expectations then >

Re: fork on processes with lots of memory

On Tue, 26 Jan 2016, Felix von Leitner wrote: > > Dear Linux kernel devs, > > > I talked to someone who uses large Linux based hardware to run a > > process with huge memory requirements (think 4 GB), and he told me that > > if they do a fork() syscall on that process, the whole system comes to >

Re: [PATCH v4] futex: Remove requirement for lock_page in get_futex_key

On Sat, 23 Jan 2016, Davidlohr Bueso wrote: > From: Mel Gorman > > When dealing with key handling for shared futexes, we can drastically reduce > the usage/need of the page lock. 1) For anonymous pages, the associated futex > object is the mm_struct which does not require the page lock. 2) For

Re: [PATCH v4] futex: Remove requirement for lock_page in get_futex_key

On Sat, 23 Jan 2016, Davidlohr Bueso wrote: > From: Mel Gorman > > When dealing with key handling for shared futexes, we can drastically reduce > the usage/need of the page lock. 1) For anonymous pages, the associated futex > object is the mm_struct which does not require the

Re: fork on processes with lots of memory

On Tue, 26 Jan 2016, Felix von Leitner wrote: > > Dear Linux kernel devs, > > > I talked to someone who uses large Linux based hardware to run a > > process with huge memory requirements (think 4 GB), and he told me that > > if they do a fork() syscall on that process, the whole system comes to >

Re: Bug in radix tree gang lookup?

On Fri, 22 Jan 2016, Matthew Wilcox wrote: > > I think there's a race in radix_tree_gang_lookup() (and > related functions). I was trying to understand why we need the > 'indirect_to_ptr()' call here: > > radix_tree_for_each_slot(slot, root, , first_index) { >

Re: Bug in radix tree gang lookup?

On Fri, 22 Jan 2016, Matthew Wilcox wrote: > > I think there's a race in radix_tree_gang_lookup() (and > related functions). I was trying to understand why we need the > 'indirect_to_ptr()' call here: > > radix_tree_for_each_slot(slot, root, , first_index) { >

Re: [PATCH] mm: vmpressure: fix scan window after SWAP_CLUSTER_MAX increase

On Mon, 16 Nov 2015, Johannes Weiner wrote: > Dear Hugh, > > [ sorry, I just noticed this email now ] No problem: as you can see, I'm very far from keeping up myself. > > On Wed, Oct 21, 2015 at 01:05:53PM -0700, Hugh Dickins wrote: > > On Wed, 21 Oct 2015, Johannes Weine

Re: WARNING in shmem_evict_inode

why do we shmem_recalc_inode() here in the swap path? Because its raison d'etre is to cope with clean sparse shmem pages being reclaimed behind our back: so here when swapping is a good place to look for that case.) But I've not now managed to reproduce this bug, even without the patch. I don't

Re: WARNING in shmem_evict_inode

in balance, instead of after). (Aside: why do we shmem_recalc_inode() here in the swap path? Because its raison d'etre is to cope with clean sparse shmem pages being reclaimed behind our back: so here when swapping is a good place to look for that case.) But I've not now managed to reproduce this bug, ev

Re: [PATCH] mm: vmpressure: fix scan window after SWAP_CLUSTER_MAX increase

On Mon, 16 Nov 2015, Johannes Weiner wrote: > Dear Hugh, > > [ sorry, I just noticed this email now ] No problem: as you can see, I'm very far from keeping up myself. > > On Wed, Oct 21, 2015 at 01:05:53PM -0700, Hugh Dickins wrote: > > On Wed, 21 Oct 2015, Johannes Weine

Re: [PATCH] tmpfs: avoid a little creat and stat slowdown

On Fri, 13 Nov 2015, Huang, Ying wrote: > > c435a390574d is the direct parent of afa2db2fb6f1 in its original git. > 43819159da2b is your patch applied on top of v4.3-rc7. The comparison > of 43819159da2b with v4.3-rc7 is as follow: ... > So you patch improved 11.9% from its base v4.3-rc7. I

Re: [PATCH v3] mm/hugetlbfs Fix bugs in fallocate hole punch of areas with holes

On Tue, 10 Nov 2015, Mike Kravetz wrote: > Hugh Dickins pointed out problems with the new hugetlbfs fallocate > hole punch code. These problems are in the routine remove_inode_hugepages > and mostly occur in the case where there are holes in the range of > pages to be removed. These

Re: [PATCH] mm/hugetlb: Unmap pages if page fault raced with hole punch

On Tue, 10 Nov 2015, Mike Kravetz wrote: > On 11/09/2015 02:55 PM, Mike Kravetz wrote: > > On 11/08/2015 11:42 PM, Hugh Dickins wrote: > >> On Fri, 30 Oct 2015, Mike Kravetz wrote: > >>> > >>> The 'next = start' code is actually from the

Re: [PATCH v3] mm/hugetlbfs Fix bugs in fallocate hole punch of areas with holes

On Tue, 10 Nov 2015, Mike Kravetz wrote: > Hugh Dickins pointed out problems with the new hugetlbfs fallocate > hole punch code. These problems are in the routine remove_inode_hugepages > and mostly occur in the case where there are holes in the range of > pages to be removed. These

Re: [PATCH] tmpfs: avoid a little creat and stat slowdown

On Fri, 13 Nov 2015, Huang, Ying wrote: > > c435a390574d is the direct parent of afa2db2fb6f1 in its original git. > 43819159da2b is your patch applied on top of v4.3-rc7. The comparison > of 43819159da2b with v4.3-rc7 is as follow: ... > So you patch improved 11.9% from its base v4.3-rc7. I

<    4   5   6   7   8   9   10   11   12   13   >