On Fri, 5 Jun 2020 13:11:34 -0700 Matthew Wilcox wrote:
> On Fri, Jun 05, 2020 at 03:58:48PM -0400, Qian Cai wrote:
> > This will trigger,
> >
> > [ 8853.759549] LTP: starting semget05
> > [ 8867.257088] BUG: sleeping function called from invalid context at
> > mm/slab.h:567
> > [ 8867.270259]
On Tue, 19 May 2020 15:28:04 +0530 Charan Teja Reddy
wrote:
> When boosting is enabled, it is observed that rate of atomic order-0
> allocation failures are high due to the fact that free levels in the
> system are checked with ->watermark_boost offset. This is not a problem
> for sleepable
On Thu, 4 Jun 2020 10:16:07 -0700 Linus Torvalds
wrote:
> On Thu, Jun 4, 2020 at 1:35 AM Joerg Roedel wrote:
> >
> > I posted the fix for this already:
> >
> > https://lore.kernel.org/lkml/20200604074446.23944-1-j...@8bytes.org/
>
> Ugh.
>
> I was going to apply this directly, but as
On Thu, 4 Jun 2020 19:48:14 +0300 Mike Rapoport wrote:
> On Thu, Jun 04, 2020 at 09:44:46AM +0200, Joerg Roedel wrote:
> > From: Joerg Roedel
> >
> > The pud_alloc_track() needs to do different checks based on whether
> > __ARCH_HAS_5LEVEL_HACK is defined, like it already does in
> >
The mm-of-the-moment snapshot 2020-06-03-17-54 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.
You
On Thu, 21 May 2020 10:42:50 -0700 Ira Weiny wrote:
> > >
> > > Actually it occurs to me that the patch consolidating kmap_prot is odd for
> > > sparc 32 bit...
> > >
> > > Its a long shot but could you try reverting this patch?
> > >
> > > 4ea7d2419e3f kmap: consolidate kmap_prot definitions
On Tue, 14 Apr 2020 18:34:49 +0300 Mike Rapoport wrote:
> Implement primitives necessary for the 4th level folding, add walks of p4d
> level where appropriate and replace 5level-fixup.h with pgtable-nop4d.h.
A bunch of new material just landed in linux-next/powerpc.
The timing is awkward! I
On Tue, 2 Jun 2020 19:57:41 +1000 Stephen Rothwell
wrote:
> Subject: [PATCH] turns out that probe_user_write is used in modular code
>
> Signed-off-by: Stephen Rothwell
> ---
> mm/maccess.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/mm/maccess.c b/mm/maccess.c
> index
On Mon, 1 Jun 2020 21:05:25 -0700 (PDT) Hugh Dickins wrote:
> Andrew, I've noticed that this buggy
> mm-compaction-avoid-vm_bug_onpageslab-in-page_mapcount.patch
> was still in Friday's mmotm 2020-05-29-16-09, despite its replacement
> 6988f31d558a ("mm: remove VM_BUG_ON(PageSlab()) from
On Mon, 1 Jun 2020 21:33:32 -0400 Rich Felker wrote:
> Hmm, it looks like Andrew Morton just pulled most of these into -mm,
> apparently independently of me getting them in my for-next a few hours
> ago, since his versions lack my signed-off-by. That's ok though, as
> long as they
On Sun, 31 May 2020 12:47:09 + Wei Yang wrote:
> On Sun, May 31, 2020 at 12:56:29AM +0300, Andy Shevchenko wrote:
> >On Sun, May 31, 2020 at 12:23 AM Wei Yang wrote:
> >> On Sat, May 30, 2020 at 01:25:31PM +0300, Andy Shevchenko wrote:
> >> >On Sat, May 30, 2020 at 12:43:28AM +, Wei
On Thu, 28 May 2020 12:19:35 -0700 (PDT) Palmer Dabbelt
wrote:
> On Thu, 28 May 2020 02:22:11 PDT (-0700), Stephen Rothwell wrote:
> > Hi all,
> >
> > Today's linux-next merge of the akpm-current tree got a conflict in:
> >
> > arch/riscv/Kconfig
> >
> > between commit:
> >
> > b151fefd23b7
On Thu, 28 May 2020 19:29:43 +1000 Stephen Rothwell
wrote:
> Hi all,
>
> Today's linux-next merge of the akpm-current tree got a conflict in:
>
> mm/memory.c
>
> between commit:
>
> 7df676974359 ("mm/memory.c: Update local TLB if PTE entry exists")
>
> from the mips tree and commit:
>
On Wed, 27 May 2020 10:25:18 +0800 Bibo Mao wrote:
> If two threads concurrently fault at the same page, the thread that
> won the race updates the PTE and its local TLB. For now, the other
> thread gives up, simply does nothing, and continues.
>
> It could happen that this second thread
On Fri, 29 May 2020 00:16:22 +0900 Tetsuo Handa
wrote:
> On 2020/05/28 20:06, Petr Mladek wrote:
> > Now, it requires lib/Kconfig.twist that is added by a patch in
> > Andrew's tree. One approach is to push this into linux-next
> > via Andrew's -mm tree.
> >
> > Another possibility would be to
strncpy_from_kernel_nofault(buf, unsafe_ptr, bufsz);
Another user of strncpy_from_unsafe() has popped up in linux-next's
bpf. I did the below, but didn't try very hard - it's probably wrong
if CONFIG_ARCH_HAS_NON_OVERLAPPING_ADDRESS_SPACE=n?
Anyway, please take a look at all the bpf_trace.c chan
On Thu, 21 May 2020 17:22:48 +0200 Christoph Hellwig wrote:
> Currently architectures have to override every routine that probes
> kernel memory, which includes a pure read and strcpy, both in strict
> and not strict variants. Just provide a single arch hooks instead to
> make sure all
On Tue, 26 May 2020 08:13:09 +0200 Christoph Hellwig wrote:
> On Mon, May 25, 2020 at 03:19:12PM -0700, Andrew Morton wrote:
> > hm. Applying linux-next to this series generates a lot of rejects against
> > powerpc:
> >
> > -rw-rw-r-- 1 akpm akpm 493 May 2
On Wed, 27 May 2020 22:45:42 + Wei Yang wrote:
> /* a tiny module only meant to test get_count_order/long */
> unsigned int order_comb[][2] = {
> {0x0003, 2},
> {0x0004, 2},
> {0x1fff, 13},
> {0x2000, 13},
> {0x5000, 32},
>
On Wed, 27 May 2020 15:41:48 -0400 Johannes Weiner wrote:
> On Wed, May 27, 2020 at 11:29:58AM -0700, Shakeel Butt wrote:
> > From: Johannes Weiner
> >
> > Currently, THP are counted as single pages until they are split right
> > before being swapped out. However, at that point the VM is
The mm-of-the-moment snapshot 2020-05-25-16-56 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.
You
On Mon, 25 May 2020 21:57:41 + Wei Yang wrote:
> I see the patch just merged, so I suppose to add the above test code into that
> one?
Well, that's not really test code.
But yes, something which tests both the 32-bit and 64-bit functions would be
nice, sometime.
On Thu, 21 May 2020 17:22:38 +0200 Christoph Hellwig wrote:
> this series start cleaning up the safe kernel and user memory probing
> helpers in mm/maccess.c, and then allows architectures to implement
> the kernel probing without overriding the address space limit and
> temporarily allowing
function on other arches, there is no negative
> influence on those architectures.
Acked-by: Andrew Morton
Should I take these, or would the mips tree be preferred? I'm OK
either way, but probably the MIPS tree would be better?
s defined as empty on other arches.
Acked-by: Andrew Morton
Thanks for persisting with these.
On Mon, 25 May 2020 10:52:37 +0800 Bibo Mao wrote:
> It is not necessary to flush tlb page on all CPUs if suitable PTE
> entry exists already during page fault handling, just updating
> TLB is fine.
>
> Here redefine flush_tlb_fix_spurious_fault as empty on MIPS system.
>
> ...
>
> ---
On Mon, 25 May 2020 18:32:16 +0300 Andy Shevchenko
wrote:
> On Mon, May 25, 2020 at 02:43:12PM +, Wei Yang wrote:
> > On Mon, May 25, 2020 at 12:14:58PM +0300, Andy Shevchenko wrote:
> > >On Sun, May 24, 2020 at 12:35:51PM +, Wei Yang wrote:
> > >> These two cases could be unified into
The mm-of-the-moment snapshot 2020-05-24-22-09 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.
You
The mm-of-the-moment snapshot 2020-05-22-20-35 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.
You
On Wed, 13 May 2020 17:05:25 +0300 Konstantin Khlebnikov
wrote:
> Function isolate_migratepages_block() runs some checks out of lru_lock
> when choose pages for migration. After checking PageLRU() it checks extra
> page references by comparing page_count() and page_mapcount(). Between
> these
On Thu, 21 May 2020 22:56:20 -0700 (PDT) Hugh Dickins wrote:
> I've only seen this livelock on one machine (repeatably, but not to
> order), and not fully analyzed it - two processes seen looping around
> getting -EEXIST from swapcache_prepare(), I guess a third (at lower
> priority? but wanting
On Fri, 22 May 2020 09:18:25 +0200 Guoqing Jiang
wrote:
> >> - ClearPagePrivate(page);
> >> - set_page_private(newpage, page_private(page));
> >> - set_page_private(page, 0);
> >> - put_page(page);
> >> + set_page_private(newpage, detach_page_private(page));
> >
On Fri, 22 May 2020 09:52:07 +0200 Marco Elver wrote:
> During early boot, while KASAN is not yet initialized, it is possible to
> enter reporting code-path and end up in kasan_report(). While
> uninitialized, the branch there prevents generating any reports,
> however, under certain
The mm-of-the-moment snapshot 2020-05-21-20-42 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.
You
On Thu, 21 May 2020 11:30:35 +0800 Bibo Mao wrote:
> If two threads concurrently fault at the same address, the thread that
> won the race updates the PTE and its local TLB. For now, the other
> thread gives up, simply does nothing, and continues.
>
> It could happen that this second thread
On Thu, 21 May 2020 16:23:06 +0100 Steven Price wrote:
> Jan alert me[1] that the W+X detection debug feature was broken in x86
> by my change[2] to switch x86 to use the generic ptdump infrastructure.
>
> Fundamentally the approach of trying to move the calculation of
> effective permissions
On Thu, 21 May 2020 17:00:04 +0530 Prakash Gupta wrote:
> Limit the iova size while freeing based on unmapped size. In absence of
> this even with unmap failure, invalid iova is pushed to iova rcache and
> subsequently can cause panic while rcache magazine is freed.
>
> Signed-off-by: Prakash
On Thu, 21 May 2020 00:50:56 -0700 Michel Lespinasse wrote:
> > > * Must be called holding task's alloc_lock to protect task's
> > > mems_allowed
> > > - * and mempolicy. May also be called holding the mmap_semaphore for
> > > write.
> > > + * and mempolicy. May also be called holding the
On Thu, 21 May 2020 13:36:28 +0900 Sergey Senozhatsky
wrote:
> On (20/05/20 18:00), Andrew Morton wrote:
> [..]
> > I'm wondering if we shold add a kernel puts() (putsk()? yuk) which can
> > puts() a string of any length.
> >
> > I'm counting arou
these files ?)
From: Andrew Morton
Subject: mmap-locking-api-convert-mmap_sem-call-sites-missed-by-coccinelle-fix
convert linux-next leftovers
Cc: Michel Lespinasse
Cc: Daniel Jordan
Cc: Laurent Dufour
Cc: Vlastimil Babka
Cc: Davidlohr Bueso
Cc: David Rientjes
Cc: Hugh Dickins
Cc: Jason G
On Tue, 19 May 2020 22:29:08 -0700 Michel Lespinasse wrote:
> Convert comments that reference mmap_sem to reference mmap_lock instead.
This may not be complete..
From: Andrew Morton
Subject: mmap-locking-api-convert-mmap_sem-comments-fix
fix up linux-next leftovers
Cc: Daniel Jordan
On Wed, 20 May 2020 11:15:02 +0800 Huang Ying wrote:
> In some swap scalability test, it is found that there are heavy lock
> contention on swap cache even if we have split one swap cache radix
> tree per swap device to one swap cache radix tree every 64 MB trunk in
> commit 4b3ef9daa4fc
On Wed, 20 May 2020 13:36:45 -0700 Joe Perches wrote:
> On Wed, 2020-05-20 at 21:10 +0900, Sergey Senozhatsky wrote:
> > On (20/05/19 21:58), Joe Perches wrote:
> > [..]
> > > > Maybe we can
> > > > use here something rather random and much shorter instead. E.g.
> > > > 256 chars. Hmm. How
> >
On Wed, 20 May 2020 14:39:13 +0800 maobibo wrote:
> > I'm still worried about the impact on other architectures. The
> > additional update_mmu_cache() calls won't occur only when multiple
> > threads are racing against the same page, I think? For example,
> > insert_pfn() will do this when
On Wed, 20 May 2020 16:20:05 +0300 Mike Rapoport wrote:
> The kbuild test robot reported the following warning:
>
> arch/sparc/mm/srmmu.c: In function 'srmmu_nocache_init':
> >> arch/sparc/mm/srmmu.c:300:9: error: variable 'pud' set but not used
> >> [-Werror=unused-but-set-variable]
> 300 |
On Wed, 20 May 2020 16:40:37 -0700 Andrew Morton
wrote:
> > -/* The number of times we should retry reclaim failures before giving up.
> > */
>
> hm, what tree is this against?
Ah, my habit of working in reverse time order sometimes does this ;)
I suggest that "
On Wed, 20 May 2020 17:31:42 +0100 Chris Down wrote:
> Reclaim retries have been set to 5 since the beginning of time in
> 66e1707bc346 ("Memory controller: add per cgroup LRU and reclaim").
> However, we now have a generally agreed-upon standard for page reclaim:
> MAX_RECLAIM_RETRIES
On Wed, 20 May 2020 12:36:36 -0700 Nick Desaulniers
wrote:
> As debug information gets larger and larger, it helps significantly save
> the size of vmlinux images to compress the information in the debug
> information sections. Note: this debug info is typically split off from
> the final
The mm-of-the-moment snapshot 2020-05-19-21-47 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.
You
On Tue, 19 May 2020 11:31:07 +0800 Xiaoming Ni wrote:
> Kernel/sysctl.c
eek!
>
> fs/proc/proc_sysctl.c| 2 +-
> include/linux/sched/sysctl.h | 14 +--
> include/linux/sysctl.h | 13 ++-
> kernel/hung_task.c | 77 +++-
> kernel/sysctl.c |
On Tue, 19 May 2020 15:28:04 +0530 Charan Teja Reddy
wrote:
> When boosting is enabled, it is observed that rate of atomic order-0
> allocation failures are high due to the fact that free levels in the
> system are checked with ->watermark_boost offset. This is not a problem
> for sleepable
On Tue, 19 May 2020 18:03:29 +0800 Bibo Mao wrote:
> Here add pte_sw_mkyoung function to make page readable on MIPS
> platform during page fault handling. This patch improves page
> fault latency about 10% on my MIPS machine with lmbench
> lat_pagefault case.
>
> It is noop function on other
On Tue, 19 May 2020 18:03:28 +0800 Bibo Mao wrote:
> If two threads concurrently fault at the same address, the thread that
> won the race updates the PTE and its local TLB. For now, the other
> thread gives up, simply does nothing, and continues.
>
> It could happen that this second thread
On Tue, 19 May 2020 15:13:13 +0200 Arnd Bergmann wrote:
> Using the socket ioctls on arch/sh (and only there) causes build
> time problems when __kernel_old_timeval/__kernel_old_timespec are
> not already visible to the compiler.
>
> Add an explict include line for the header that defines these
On Tue, 19 May 2020 23:05:46 +0200 Andrey Konovalov
wrote:
> On Tue, May 19, 2020 at 8:25 PM Marco Elver wrote:
> >
> > During early boot, while KASAN is not yet initialized, it is possible to
> > enter reporting code-path and end up in kasan_report(). While
> > uninitialized, the branch there
On Tue, 19 May 2020 22:19:08 +0200 Sebastian Andrzej Siewior
wrote:
> From: Ingo Molnar
>
> The various struct pagevec per CPU variables are protected by disabling
> either preemption or interrupts across the critical sections. Inside
> these sections spinlocks have to be acquired.
>
> These
On Sun, 17 May 2020 23:47:18 +0200 Guoqing Jiang
wrote:
> We can cleanup code a little by call detach_page_private here.
>
> ...
>
> --- a/mm/migrate.c
> +++ b/mm/migrate.c
> @@ -804,10 +804,7 @@ static int __buffer_migrate_page(struct address_space
> *mapping,
> if (rc !=
On Tue, 19 May 2020 11:29:46 +0800 王程刚 wrote:
> Function pr_notice print max length maybe less than the command line length,
> need more times to print all.
> For example, arm64 has 2048 bytes command line length, but printk maximum
> length is only 1024 bytes.
I can see why that might be a
On Tue, 19 May 2020 11:22:49 +0800 maobibo wrote:
> how about adding pte_sw_mkyoung alike function which is a noop on all but
> mips?
> this function is used to set PAGE_ACCESS bit and PAGE_VALID bit on mips
> platform.
Sounds good. Please ensure that the interface (roles and
On Mon, 18 May 2020 14:13:50 -0700 Minchan Kim wrote:
> Andrew, I sent this patch without folding into previous syscall introducing
> patches because it could be arguable. If you want to fold it into each
> patchset(i.e., introdcuing process_madvise syscall and introducing
> compat_syscall), let
On Sat, 16 May 2020 14:47:40 +0800 Feng Tang wrote:
> When checking a performance change for will-it-scale scalability
> mmap test [1], we found very high lock contention for spinlock of
> percpu counter 'vm_committed_as':
>
> 94.14% 0.35% [kernel.kallsyms] [k]
On Sat, 16 May 2020 14:56:41 +0200 Joerg Roedel wrote:
> Hi Andrew,
>
> On Fri, May 15, 2020 at 01:01:42PM -0700, Andrew Morton wrote:
> > On Fri, 15 May 2020 16:00:18 +0200 Joerg Roedel wrote:
> > Lots of collisions here with Christoph's "decruft the vma
On Sun, 17 May 2020 16:56:19 -0700 John Hubbard wrote:
> In the case of get_user_pages_fast() returning fewer pages than
> requested, rio_dma_transfer() does not quite do the right thing.
> It attempts to release all the pages that were requested, rather
> than just the pages that were pinned.
>
On Mon, 18 May 2020 13:08:49 +0800 Bibo Mao wrote:
> On mips platform, hw PTE entry valid bit is set in pte_mkyoung
> function, it is used to set physical page with readable privilege.
pte_mkyoung() seems to be a strange place to set the pte's valid bit.
Why is it done there? Can it be done
The following commit has been merged into the x86/build branch of tip:
Commit-ID: 0be11088b848774ae1f693169fdb9575e0ff06ba
Gitweb:
https://git.kernel.org/tip/0be11088b848774ae1f693169fdb9575e0ff06ba
Author:Andrew Morton
AuthorDate:Tue, 05 May 2020 14:26:51 -07:00
The mm-of-the-moment snapshot 2020-05-15-16-29 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.
You
On Thu, 14 May 2020 15:04:24 +0800 Huang Ying wrote:
> In some swap scalability test, it is found that there are heavy lock
> contention on swap cache even if we have split one swap cache radix
> tree per swap device to one swap cache radix tree every 64 MB trunk in
> commit 4b3ef9daa4fc
On Fri, 15 May 2020 12:10:08 +0800 Bibo Mao wrote:
> If there are two threads hitting page fault at the same page,
> one thread updates PTE entry and local TLB, the other can
> update local tlb also, rather than give up and do page fault
> again.
>
> ...
>
> --- a/mm/memory.c
> +++ b/mm/memory.c
be called.
Link: http://lkml.kernel.org/r/20200515140023.25469-3-j...@8bytes.org
Signed-off-by: Joerg Roedel
Acked-by: Andy Lutomirski
Signed-off-by: Andrew Morton
---
include/linux/vmalloc.h | 16 ++
mm/vmalloc.c| 91 +++---
2 files changed, 81 inser
2412.1625-1-d...@arista.com/T/#u
Link: http://lkml.kernel.org/r/20200418201944.482088-13-d...@arista.com
Signed-off-by: Dmitry Safonov
Cc: Guo Ren
Signed-off-by: Andrew Morton
---
arch/csky/kernel/stacktrace.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
--- a/arch/csky/kernel/stacktrace.
Stafford Horne
Cc: Stefan Kristiansson
Cc: Suzuki K Poulose
Cc: Tony Luck
Cc: Will Deacon
Cc: Yoshinori Sato
Signed-off-by: Andrew Morton
---
arch/arm64/include/asm/kvm_mmu.h| 10 -
arch/arm64/include/asm/pgalloc.h| 10 -
arch/arm64/include/asm/pgtable-types.h |
The mm-of-the-moment snapshot 2020-05-13-20-30 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.
You
On Tue, 12 May 2020 17:29:36 -0400 Johannes Weiner wrote:
> + inode_pages_clear(mapping->inode);
> + else if (populated == 1)
> + inode_pages_set(mapping->inode);
mapping->host...
I have to assume this version wasn't runtime tested, so I'll drop it.
On Wed, 13 May 2020 15:16:53 +0530 Charan Teja Kalla
wrote:
> So, yes, this problem is got fixed with the changes made in this patch.
OK, thanks.
Could you please prepare a v2 with a changelog which includes the
additional info in your two replies?
On Tue, 12 May 2020 17:29:36 -0400 Johannes Weiner wrote:
>
> ...
>
> Solution
>
> This patch fixes the aging inversion described above on
> !CONFIG_HIGHMEM systems, without reintroducing the problems associated
> with excessive shrinker LRU rotations, by keeping populated inodes off
> the
On Wed, 13 May 2020 17:05:25 +0300 Konstantin Khlebnikov
wrote:
> Function isolate_migratepages_block() runs some checks out of lru_lock
> when choose pages for migration. After checking PageLRU() it checks extra
> page references by comparing page_count() and page_mapcount(). Between
> these
On Tue, 12 May 2020 13:46:53 -0400 Rafael Aquini wrote:
> The sysctl knob
/proc/sys/kernel/tainted, yes?
> allows users with SYS_ADMIN capability to
> taint the kernel with any arbitrary value, but this might
> produce an invalid flags bitset being committed to tainted_mask.
>
> This patch
The mm-of-the-moment snapshot 2020-05-11-15-43 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.
You
On Mon, 11 May 2020 14:38:23 -0700 Shakeel Butt wrote:
> On Mon, May 11, 2020 at 2:11 PM Andrew Morton
> wrote:
> >
> > On Sat, 9 May 2020 07:19:46 -0700 Shakeel Butt wrote:
> >
> > > Currently, THP are counted as single pages until they are split rig
On Sat, 9 May 2020 07:19:46 -0700 Shakeel Butt wrote:
> Currently, THP are counted as single pages until they are split right
> before being swapped out. However, at that point the VM is already in
> the middle of reclaim, and adjusting the LRU balance then is useless.
>
> Always account THP
On Mon, 11 May 2020 19:10:08 +0530 Charan Teja Reddy
wrote:
> Updating the zone watermarks by any means, like extra_free_kbytes,
> min_free_kbytes, water_mark_scale_factor e.t.c, when watermark_boost is
> set will result into the higher low and high watermarks than the user
> asks. This can be
On Fri, 1 May 2020 15:20:44 -0300 Jason Gunthorpe wrote:
> From: Jason Gunthorpe
>
> There is no reason for a user to select this or not directly - it should
> be selected by drivers that are going to use the feature, similar to how
> CONFIG_HMM_MIRROR works.
>
> Currently all drivers
On Sat, 9 May 2020 10:19:19 +1000 Stephen Rothwell
wrote:
> Hi all,
>
> Commits
>
> a41ffad2df78 ("mm: free_area_init: allow defining max_zone_pfn in
> descending order")
Look OK to me?
On Fri, 8 May 2020 10:42:14 +0200 David Hildenbrand wrote:
> Assume we have kmem configured and loaded:
> [root@localhost ~]# cat /proc/iomem
> ...
> 14000-33fff : Persistent Memory$
> 14000-1481f : namespace0.0
> 15000-33fff : dax0.0
>
On Fri, 8 May 2020 11:36:53 -0700 Minchan Kim wrote:
>
> ...
>
> Per Vlastimil's request, I changed "which and advise" with "idtype and
> advice" in function prototype of description.
> Could you replace the part in the description? Code is never changed.
>
Done, but...
>
> ...
>
> There is
On Fri, 8 May 2020 07:51:23 -0700 Ira Weiny wrote:
> This should probably be squashed into that patch though...
>
> Andrew do you want a V3.1?
Is OK, I'll always fold foo-fix.patch into foo.patch before sending it onwards.
t;
> > 6b66ab470b4d ("arch/kunmap: remove duplicate kunmap implementations")
> >
> > kunmap_high() is now only declared when CONFIG_HIGHMEM is defined.
>
> Is there anything that can be done quickly about this as it broke a
> large number of builds
On Wed, 6 May 2020 10:18:24 +0800 Walter Wu wrote:
> On Wed, 2020-04-22 at 18:21 -0700, Bart Van Assche wrote:
> > On 4/20/20 6:35 PM, Walter Wu wrote:
> > > Modify the variable type of 'skip' member of struct stack_trace.
> > > In theory, the 'skip' variable type should be unsigned int.
> > >
On Wed, 6 May 2020 09:25:54 +0300 Vasily Averin wrote:
> new_pos should jump through hole of unused ids,
> pos can be updated inside "for" cycle.
>
> Cc: sta...@vger.kernel.org
> Fixes: 89163f93c6f9 ("ipc/util.c: sysvipc_find_ipc() should increase position
> index")
This:
> --- a/ipc/util.c
On Wed, 6 May 2020 14:21:28 +0800 Tan Hu wrote:
> If the given type has fraction smaller than max_frac/FPROP_FRAC_BASE,
> __fprop_inc_percpu_max should follow the design formula and aging
> fraction too.
>
> Signed-off-by: Tan Hu
> ---
> lib/flex_proportions.c | 7 +++
> 1 file changed, 3
On Thu, 7 May 2020 18:46:24 -0300 "Guilherme G. Piccoli"
wrote:
> After a recent change introduced by Vlastimil's series [0], kernel is
> able now to handle sysctl parameters on kernel command line; also, the
> series introduced a simple infrastructure to convert legacy boot
> parameters (that
On Thu, 7 May 2020 18:59:46 -0300 "Guilherme G. Piccoli"
wrote:
> Currently we have no way to determine if compaction was triggered
> by sysctl write, but this is an interesting information to have,
> specially in systems with high uptime that presents lots of
> fragmented memory. There's no
ase report
them to the maintainer, see CHECKPATCH in MAINTAINERS.
Please run checkpatch prior to sending patches
Cc: Ira Weiny
Signed-off-by: Andrew Morton
---
arch/sparc/include/asm/highmem.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
---
a/arch/sparc/include/asm/highm
On Thu, 7 May 2020 08:00:01 -0700 ira.we...@intel.com wrote:
> parisc reimplements the kmap calls except to flush it's dcache. This is
> arguably an abuse of kmap but regardless it is messy and confusing.
>
> Remove the duplicate code and have parisc define
> ARCH_HAS_FLUSH_ON_KUNMAP for a
On Wed, 6 May 2020 17:42:40 -0700 "Paul E. McKenney" wrote:
> This commit adds a shrinker so as to inform RCU when memory is scarce.
> RCU responds by shifting into the same fast and inefficient mode that is
> used in the presence of excessive numbers of RCU callbacks. RCU remains
> in this
The following commit has been merged into the x86/build branch of tip:
Commit-ID: 950a37078aa0ab63a57673e7027e8735e73d4bc6
Gitweb:
https://git.kernel.org/tip/950a37078aa0ab63a57673e7027e8735e73d4bc6
Author:Andrew Morton
AuthorDate:Tue, 05 May 2020 14:26:51 -07:00
On Tue, 07 Apr 2020 21:21:57 +0100 David Howells wrote:
> David Howells wrote:
>
> > > if (unlikely(key_data))
> > > - __kvzfree(key_data, key_data_len);
> > > + kvfree_sensitive(key_data, key_data_len);
> >
> > I think the
On Tue, 5 May 2020 08:21:34 +0530 Anshuman Khandual
wrote:
> >>> static inline void arch_clear_hugepage_flags(struct page *page)
> >>> {
> >>>
> >>> }
> >>> #define arch_clear_hugepage_flags arch_clear_hugepage_flags
> >>>
> >>> It's a small difference - mainly to avoid adding two variables
On Tue, 05 May 2020 10:42:05 +0200 Roman Penyaev wrote:
> May I ask you to remove "epoll: ensure ep_poll() doesn't miss wakeup
> events" from your -mm queue? Jason lately found out that the patch
> does not fully solve the problem and this one patch is a second
> attempt to do things correctly
On Tue, 5 May 2020 15:26:13 +0200 Geert Uytterhoeven
wrote:
> While "git am" can apply an mbox file containing multiple patches (e.g.
> as created by b4[1], or a patch bundle downloaded from patchwork),
> checkpatch does not have proper support for that. When operating on an
> mbox,
501 - 600 of 25528 matches
Mail list logo
