On Thu, 11 Apr 2024 17:40:02 +0200 Michal Koutný wrote:
> Hello.
>
> On Mon, Apr 08, 2024 at 01:29:55PM -0700, Andrew Morton
> wrote:
> > That seems like a large change.
>
> In what sense is it large?
A large increase in the maximum number of processes. Or did I misinterpret?
On Fri, 5 Apr 2024 07:58:11 -0400 Paolo Bonzini wrote:
> Please review! Also feel free to take the KVM patches through the mm
> tree, as I don't expect any conflicts.
It's mainly a KVM thing and the MM changes are small and simple.
I'd say that the KVM tree would be a better home?
On Tue, 9 Apr 2024 12:00:06 -0700 "Ho-Ren (Jack) Chuang"
wrote:
> Hi Jonathan,
>
> On Fri, Apr 5, 2024 at 6:56 AM Jonathan Cameron
> wrote:
> >
> > On Fri, 5 Apr 2024 00:07:05 +
> > "Ho-Ren (Jack) Chuang" wrote:
> >
> > > Since different memory devices require finding, allocating, and
On Mon, 8 Apr 2024 16:58:18 +0200 Michal Koutný wrote:
> The kernel provides mechanisms, while it should not imply policies --
> default pid_max seems to be an example of the policy that does not fit
> all. At the same time pid_max must have some value assigned, so use the
> end of the allowed
On Tue, 02 Apr 2024 00:24:28 -0600 Vishal Verma
wrote:
> In [1], Dan points out that all of the WARN_ON_ONCE() usage in the
> referenced patch should be replaced with lockdep_assert_held(_write)().
>
> Replace those, and additionally, replace a couple of other
> WARN_ON_ONCE() introduced in
On Tue, 12 Mar 2024 20:20:17 + "Verma, Vishal L"
wrote:
> > All of these WARN_ON_ONCE() usages should be replaced with
> > lockdep_assert_held() and lockdep_assert_held_write() where appropriate.
>
> Makes sense - I can send a patch post -rc1 to change these if that's okay
> Andrew?
On Mon, 19 Feb 2024 02:35:20 -0500 "Michael S. Tsirkin" wrote:
> On Sun, Feb 18, 2024 at 09:06:18PM -0800, syzbot wrote:
> > Hello,
> >
> > syzbot found the following issue on:
> >
> > HEAD commit:d37e1e4c52bc Add linux-next specific files for 20240216
> > git tree: linux-next
> >
On Sat, 17 Feb 2024 16:18:10 +0800 Changbin Du wrote:
> The synchronization here is just to ensure the module init's been freed
> before doing W+X checking. But the commit 1a7b7d922081 ("modules: Use
> vmalloc special flag") moves do_free_init() into a global workqueue
> instead of call_rcu().
On Wed, 24 Jan 2024 12:03:45 -0800 Vishal Verma
wrote:
> This series adds sysfs ABI to control memmap_on_memory behavior for DAX
> devices.
Thanks. I'll add this to mm-unstable for some additional testing, but
I do think we should have the evidence of additional review on this
series's four
On Wed, 17 Jan 2024 06:16:36 + Chen Zhongjin
wrote:
> There is a deadlock scenario in kprobe_optimizer():
>
> pid A pid B pid C
> kprobe_optimizer()do_exit() perf_kprobe_init()
> mutex_lock(_mutex)
On Tue, 19 Dec 2023 22:12:31 +0800 Changbin Du wrote:
> The commit 1a7b7d922081 ("modules: Use vmalloc special flag") moves
> do_free_init() into a global workqueue instead of call_rcu(). So now
> we should wait it via flush_work().
What are the runtime effects of this change?
On Mon, 11 Dec 2023 19:26:40 -0800 Bixuan Cui wrote:
> -TRACE_EVENT(mm_vmscan_lru_shrink_inactive,
> +TRACE_EVENT(mm_vmscan_lru_shrink_inactive_start,
Current kernels have a call to trace_mm_vmscan_lru_shrink_inactive() in
evict_folios(), so this renaming broke the build.
search path can be extended by a space separated list of paths passed
> to the
> lx-symbols command.
>
> Note how that talks about a "space separated list of paths" for which
> clearly a single path seems like it should be accepted?
>
> > @@ -138,6 +13
On Fri, 21 Jul 2023 14:15:31 +1000 Alistair Popple wrote:
> Thanks for this Huang, I had been hoping to take a look at it this week
> but have run out of time. I'm keen to do some testing with it as well.
Thanks. I'll queue this in mm-unstable for some testing. Detailed
review and testing
tps://lkml.kernel.org/r/1669972991-246-1-git-send-email-ruansy.f...@fujitsu.com
Signed-off-by: Shiyang Ruan
Cc: Alistair Popple
Cc: Dan Williams
Cc: Darrick J. Wong
Cc: Dave Chinner
Cc: Jason Gunthorpe
Cc: John Hubbard
Signed-off-by: Andrew Morton
---
fs/dax.c | 12 ++--
1 file
On Thu, 1 Dec 2022 15:58:11 -0800 "Darrick J. Wong" wrote:
> > --- a/fs/dax.c
> > +++ b/fs/dax.c
> > @@ -1092,7 +1092,7 @@ static int dax_iomap_direct_access(const struct iomap
> > *iomap, loff_t pos,
> > }
> >
> > /**
> > - * dax_iomap_cow_copy - Copy the data from source to destination
On Tue, 29 Nov 2022 19:59:14 -0800 Dan Williams
wrote:
> [ add Andrew ]
>
> Shiyang Ruan wrote:
> > Many testcases failed in dax+reflink mode with warning message in dmesg.
> > This also effects dax+noreflink mode if we run the test after a
> > dax+reflink test. So, the most urgent thing is
On Thu, 8 Sep 2022 15:51:50 -0700 Dan Williams wrote:
> Jonathan Cameron wrote:
> > On Wed, 7 Sep 2022 18:07:31 -0700
> > Dan Williams wrote:
> >
> > > Andrew Morton wrote:
> > > > I really dislike the term "flush". Sometimes it means writeb
I really dislike the term "flush". Sometimes it means writeback,
sometimes it means invalidate. Perhaps at other times it means
both.
Can we please be very clear in comments and changelogs about exactly
what this "flush" does. With bonus points for being more specific in the
function naming?
On Wed, 6 Jul 2022 10:47:32 +0800 Muchun Song wrote:
> > If this wakeup is not one of these, then are there reports from the
> > softlockup detector?
> >
> > Do we have reports of processes permanently stuck in D state?
> >
>
> No. The task is in an TASK_INTERRUPTIBLE state (see
>
On Wed, 6 Jul 2022 00:38:41 +0100 Matthew Wilcox wrote:
> On Tue, Jul 05, 2022 at 02:18:19PM -0700, Andrew Morton wrote:
> > On Tue, 5 Jul 2022 20:35:32 +0800 Muchun Song
> > wrote:
> >
> > > FSDAX page refcounts are 1-based, rather than 0-based: if refc
On Tue, 5 Jul 2022 20:35:32 +0800 Muchun Song wrote:
> FSDAX page refcounts are 1-based, rather than 0-based: if refcount is
> 1, then the page is freed. The FSDAX pages can be pinned through GUP,
> then they will be unpinned via unpin_user_page() using a folio variant
> to put the page,
Unless there be last-minute objections, I plan to move this series into
the non-rebasing mm-stable branch a few days from now.
On Sun, 8 May 2022 22:36:06 +0800 Shiyang Ruan wrote:
> This is a combination of two patchsets:
> 1.fsdax-rmap:
> https://lore.kernel.org/linux-xfs/20220419045045.1664996-1-ruansy.f...@fujitsu.com/
> 2.fsdax-reflink:
>
On Thu, 2 Jun 2022 10:18:09 -0700 "Darrick J. Wong" wrote:
> On Thu, Jun 02, 2022 at 05:42:13PM +0800, Shiyang Ruan wrote:
> > Hi,
> >
> > Is there any other work I should do with these two patchsets? I think they
> > are good for now. So... since the 5.19-rc1 is coming, could the
> >
On Tue, 10 May 2022 19:43:01 -0700 "Darrick J. Wong" wrote:
> On Tue, May 10, 2022 at 07:28:53PM -0700, Andrew Morton wrote:
> > On Tue, 10 May 2022 18:55:50 -0700 Dan Williams
> > wrote:
> >
> > > > It'll need to be a stable branch somewhere, but I
On Tue, 10 May 2022 18:55:50 -0700 Dan Williams
wrote:
> > It'll need to be a stable branch somewhere, but I don't think it
> > really matters where al long as it's merged into the xfs for-next
> > tree so it gets filesystem test coverage...
>
> So how about let the notify_failure() bits go
On Thu, 31 Mar 2022 11:55:47 -0400 Qian Cai wrote:
> On Fri, Mar 18, 2022 at 03:45:23PM +0800, Muchun Song wrote:
> > This series is based on next-20220225.
> >
> > Patch 1-2 fix a cache flush bug, because subsequent patches depend on
> > those on those changes, there are placed in this series.
On Mon, 28 Feb 2022 14:35:34 +0800 Muchun Song wrote:
> The devmap pages can not use page_vma_mapped_walk() to check if a huge
> devmap page is mapped into a vma. Add support for walking huge devmap
> pages so that DAX can use it in the next patch.
>
x86_64 allnoconfig:
In file included from
On Thu, 15 Apr 2021 13:56:24 +0200 "Christian König"
wrote:
> @@ -530,6 +525,11 @@ void ttm_pool_fini(struct ttm_pool *pool)
> for (j = 0; j < MAX_ORDER; ++j)
> ttm_pool_type_fini(>caching[i].orders[j]);
> }
> +
> + /* We removed the
On Thu, 15 Apr 2021 12:23:55 +0200 Christophe Leroy
wrote:
> > +* is done. STRICT_MODULE_RWX may require extra work to support this
> > +* too.
> > +*/
> >
> > - return __vmalloc_node_range(size, 1, MODULES_VADDR, MODULES_END,
> > GFP_KERNEL,
> > -
On Sun, 11 Apr 2021 15:17:56 -0700 Randy Dunlap wrote:
> Fix various kernel-doc warnings in lib/ due to missing or
> erroneous function names.
> Add kernel-doc for some function parameters that was missing.
> Use kernel-doc "Return:" notation in earlycpio.c.
>
> Quietens the following warnings:
On Sun, 11 Apr 2021 11:53:33 +0100 Catalin Marinas
wrote:
> Hi Andrew,
>
> On Tue, Mar 30, 2021 at 10:36:37PM -0700, Andrew Morton wrote:
> > On Mon, 29 Mar 2021 16:54:26 +0200 Andrey Konovalov
> > wrote:
> > > Looks like my patch "kasan: fix
On Fri, 9 Apr 2021 08:44:39 +0200 Greg Kroah-Hartman
wrote:
> On Thu, Apr 08, 2021 at 10:05:02PM -0700, Andrew Morton wrote:
> > On Thu, 8 Apr 2021 15:06:05 +0200 Gioh Kim wrote:
> >
> > > As the name shows, it checks if strings are equal in case insensitive
> >
arvesting mailing lists.
>
> But I will appreciate it if somebody can run this through various build tests.
>
um, did you try x86_64 allmodconfig?
I'm up to
kernelh-split-out-panic-and-oops-helpers-fix-fix-fix-fix-fix-fix-fix.patch
and counting.
From: Andrew Morton
Subject: kernelh-spli
On Wed, 07 Apr 2021 22:38:37 +0200 Oscar Salvador wrote:
> On 2021-04-06 22:28, Oscar Salvador wrote:
> > Heh, it seems I spaced out today.
> >
> > We need a few things on top:
> >
>
Yes please.
On Thu, 8 Apr 2021 09:11:30 +0200 Oscar Salvador wrote:
> But if It is going to be easier for Andrew, just pull them all out and I
> will resend the whole series once this work goes in.
I think so.
I shall drop these:
mmpage_alloc-bail-out-earlier-on-enomem-in-alloc_contig_migrate_range.patch
On Thu, 8 Apr 2021 15:06:05 +0200 Gioh Kim wrote:
> As the name shows, it checks if strings are equal in case insensitive
> manner.
Peh. Who would die if we simply made sysfs_streq() case-insensitive?
On Thu, 8 Apr 2021 14:26:58 +0800 Tian Tao wrote:
> Remove including that don't need it.
>
Um, how can version.c possibly not include version.h?
Sure, it may obtain access to version.h via some other include, but
that's plain luck and nonsense. And it's unreliable and it requires
On Thu, 8 Apr 2021 16:43:18 -0700 Axel Rasmussen
wrote:
> The idea is that it will apply cleanly to akpm's tree, *replacing* the
> following
> patches (i.e., drop these first, and then apply this series):
>
> userfaultfd-support-minor-fault-handling-for-shmem.patch
>
On Fri, 9 Apr 2021 11:17:49 +0800 Miaohe Lin wrote:
> On 2021/4/9 7:25, Mike Kravetz wrote:
> > On 4/2/21 2:32 AM, Miaohe Lin wrote:
> >> A rare out of memory error would prevent removal of the reserve map region
> >> for a page. hugetlb_fix_reserve_counts() handles this rare case to avoid
> >>
On Wed, 7 Apr 2021 14:28:21 -0700 Nick Desaulniers
wrote:
> On Wed, Apr 7, 2021 at 2:21 PM Andrew Morton
> wrote:
> >
> > On Wed, 7 Apr 2021 11:54:55 -0700 Nick Desaulniers
> > wrote:
> >
> > > LLVM changed the expected function signature for
> >
On Wed, 7 Apr 2021 11:54:55 -0700 Nick Desaulniers
wrote:
> LLVM changed the expected function signature for
> llvm_gcda_emit_function() in the clang-11 release. Users of clang-11 or
> newer may have noticed their kernels producing invalid coverage
> information:
>
> $ llvm-cov gcov -a -c -u
On Mon, 5 Apr 2021 20:22:26 -0700 Davidlohr Bueso wrote:
> On Mon, 05 Apr 2021, Andrew Morton wrote:
>
> >Tricky. 339ddb53d373 was merged in December 2019. So do we backport
> >this fix? Could any userspace code be depending upon the
> >post-339ddb53d373 behavio
On Sat, 3 Apr 2021 14:31:43 +0200 Uladzislau Rezki wrote:
> >
> > We may need to replaced that kcalloc() with kmvalloc() though...
> >
> Yep. If we limit to USHRT_MAX, the maximum amount of memory for
> internal data would be ~12MB. Something like below:
>
> diff --git a/lib/test_vmalloc.c
On Mon, 5 Apr 2021 16:10:25 -0700 Davidlohr Bueso wrote:
> 339ddb53d373 (fs/epoll: remove unnecessary wakeups of nested epoll) changed
> the userspace visible behavior of exclusive waiters blocked on a common
> epoll descriptor upon a single event becoming ready. Previously, all tasks
> doing
On Mon, 5 Apr 2021 02:16:25 +0800 kernel test robot wrote:
> Hi Andrey,
>
> First bad commit (maybe != root cause):
>
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> master
> head: 2023a53bdf41b7646b1d384b6816af06309f73a5
> commit:
On Wed, 31 Mar 2021 20:35:02 -0700 Roman Gushchin wrote:
> On Thu, Apr 01, 2021 at 11:31:16AM +0800, Miaohe Lin wrote:
> > On 2021/4/1 11:01, Muchun Song wrote:
> > > Christian Borntraeger reported a warning about "percpu ref
> > > (obj_cgroup_release) <= 0 (-1) after switching to atomic".
> > >
On Fri, 2 Apr 2021 15:03:37 +0800 Stillinux wrote:
> In the case of high system memory and load pressure, we ran ltp test
> and found that the system was stuck, the direct memory reclaim was
> all stuck in io_schedule, the waiting request was stuck in the blk_plug
> flow of one process, and this
On Fri, 2 Apr 2021 22:22:34 +0200 "Uladzislau Rezki (Sony)"
wrote:
> By using this parameter we can specify how many workers are
> created to perform vmalloc tests. By default it is one CPU.
> The maximum value is set to 1024.
>
> As a result of this change a 'single_cpu_test' one becomes
>
On Thu, 1 Apr 2021 12:50:31 +0300 Andy Shevchenko
wrote:
> > I normally don't have a lot of material for asm-generic either, half
> > the time there are no pull requests at all for a given release. I would
> > expect future changes to the bitmap implementation to only need
> > an occasional
On Thu, 1 Apr 2021 19:09:43 +0800 Wan Jiabing wrote:
> checkdeclares: find struct declared more than once.
> Inspired by checkincludes.pl.
> This script checks for duplicate struct declares.
> Note that this will not take into consideration macros, so
> you should run this only if you know you
On Thu, 1 Apr 2021 21:22:48 +0800 Qiheng Lin wrote:
> Fix the following W=1 kernel build warning(s):
> mm/vmalloc.c:425: warning: expecting prototype for vunmap_range_noflush().
> Prototype was for vunmap_range() instead
>
> ...
>
> --- a/mm/vmalloc.c
> +++ b/mm/vmalloc.c
> @@ -413,7 +413,7
On Thu, 1 Apr 2021 10:26:36 -0400 Pavel Tatashin
wrote:
> On Wed, Mar 31, 2021 at 12:38 PM Mike Rapoport wrote:
> >
> > From: Mike Rapoport
> >
> > The renaming of PF_MEMALLOC_NOCMA to PF_MEMALLOC_PIN missed one occurrence
> > in mm/hugetlb.c which causes build error:
> >
> > CC
On Thu, 1 Apr 2021 23:30:10 +0100 Sergei Trofimovich wrote:
> Before the change page_owner recursion was detected via fetching
> backtrace and inspecting it for current instruction pointer.
> It has a few problems:
> - it is slightly slow as it requires extra backtrace and a linear
> stack
On Wed, 31 Mar 2021 09:44:47 +0100 Sergei Trofimovich wrote:
> ia64 has two stacks:
> - memory stack (or stack), pointed at by by r12
> - register backing store (register stack), pointed at
> ar.bsp/ar.bspstore with complications around dirty
> register frame on CPU.
>
> In
On Wed, 31 Mar 2021 22:45:12 +0800 Muchun Song wrote:
>
> Hi Andrew,
>
> Now we have two choices to fix this issue.
>
> 1) Send a v6 patchset (Use obj_cgroup APIs to charge kmem pages)
> to fix this issue.
> 2) Send a separate fix patch (Just like above).
>
> Both ways are ok for me. But
On Wed, 31 Mar 2021 16:49:27 +0200 Michal Hocko wrote:
> > Thanks for the clarification! I have suspected this to be the case but
> > I am not really familiar with the interface to have any strong statement
> > here. Maybe we want to document this explicitly.
>
> Btw. Andrew the patch still
On Mon, 29 Mar 2021 20:36:35 +0800 qianjun.ker...@gmail.com wrote:
> From: jun qian
>
> In our project, Many business delays come from fork, so
> we started looking for the reason why fork is time-consuming.
> I used the ftrace with function_graph to trace the fork, found
> that the
On Mon, 29 Mar 2021 16:54:26 +0200 Andrey Konovalov
wrote:
> Looks like my patch "kasan: fix KASAN_STACK dependency for HW_TAGS"
> that was merged into 5.12-rc causes a build time warning:
>
> include/linux/kasan.h:333:30: warning: 'CONFIG_KASAN_STACK' is not
> defined, evaluates to 0
On Tue, 30 Mar 2021 10:58:43 +0200 David Hildenbrand wrote:
> >
> > MAINTAINERS| 1 +
> > arch/alpha/include/uapi/asm/mman.h | 3 +
> > arch/mips/include/uapi/asm/mman.h | 3 +
> > arch/parisc/include/uapi/asm/mman.h| 3 +
> >
On Tue, 30 Mar 2021 09:52:26 -0500 "Gustavo A. R. Silva"
wrote:
> Fix the following out-of-bounds warnings by enclosing
> structure members file and finder into new struct info:
>
> fs/hfsplus/xattr.c:300:5: warning: 'memcpy' offset [65, 80] from the object
> at 'entry' is out of the bounds
On Tue, 30 Mar 2021 22:19:04 +0530 Naresh Kamboju
wrote:
> While running kselftest gpio on x86_64 and i386 the following warnings were
> noticed and the device did not recover.
I doubt if changes in the core code caused this. Let's cc the
gpoi-mockup developers.
> GOOD: next-20210329
> BAD:
On Mon, 22 Mar 2021 22:26:24 +0100 Ingo Molnar wrote:
> * Randy Dunlap wrote:
>
> > > New version attached. Can I add your Reviewed-by?
> >
> > Sure.
> > Reviewed-by: Randy Dunlap
>
> -v3 attached, the only change is the addition of your Reviewed-by.
>
> This would be for -mm I suppose, if
On Mon, 22 Mar 2021 13:48:35 -0700 Axel Rasmussen
wrote:
> This fix is analogous to Peter Xu's fix for hugetlb [0]. If we don't
> put_page() after getting the page out of the page cache, we leak the
> reference.
>
> The fix can be verified by checking /proc/meminfo and running the
>
On Tue, 23 Mar 2021 11:29:56 +0800 Wan Jiabing wrote:
> string.h has been included at line 15.So we remove the
> duplicate one at line 17.
Thanks. But we already have
https://lkml.kernel.org/r/20210316073336.426255-1-zhang.yun...@zte.com.cn.
On Tue, 23 Mar 2021 23:32:57 +0100 Marco Elver wrote:
> On Tue, 23 Mar 2021 at 07:45, 'Dmitry Vyukov' via kasan-dev
> wrote:
> > On Tue, Mar 23, 2021 at 7:24 AM tl455047 wrote:
> > >
> > > Fixed a typo in comment.
> > >
> > > Signed-off-by: tl455047
> >
> > Reviewed-by: Dmitry Vyukov
> >
> >
On Tue, 23 Mar 2021 13:51:32 +0100 Marco Elver wrote:
> On Tue, 23 Mar 2021 at 13:41, Arnd Bergmann wrote:
> >
> > From: Arnd Bergmann
> >
> > gcc-11 adds support for -fsanitize=kernel-hwaddress, so it becomes
> > possible to enable CONFIG_KASAN_SW_TAGS.
> >
> > Unfortunately this fails to
On Wed, 24 Mar 2021 11:20:45 +0100 John Paul Adrian Glaubitz
wrote:
> >> #NEXT_PATCHES_START mainline-later (next week, approximately)
> >> ia64-mca-allocate-early-mca-with-gfp_atomic.patch
>
> Great, thanks. We're still missing Valentin's patch for the NUMA enumeration
> issue
> though.
> Let's remove /dev/kmem, which is unused and obsolete.
I grabbed these. Silently - the cc list is amazing ;)
I was wondering if it would be better to permanently disable /dev/kmem
in Kconfig along with a comment "if you really want this thing then
email peeps@places with a very good reason
On Thu, 18 Mar 2021 13:06:17 + Valentin Schneider
wrote:
> John Paul reported a warning about bogus NUMA distance values spurred by
> commit:
>
> 620a6dc40754 ("sched/topology: Make sched_init_numa() use a set for the
> deduplicating sort")
>
> In this case, the afflicted machine comes
On Fri, 19 Mar 2021 22:24:28 +0700 Bui Quang Minh
wrote:
> userfaultfd_writeprotect() use change_protection() to clear write bit in
> page table entries (pte/pmd). So, later write to this virtual address
> range causes a page fault, which is then handled by userspace program.
> However,
On Fri, 19 Mar 2021 10:51:27 -0700 Minchan Kim wrote:
> Pages containing buffer_heads that are in one of the per-CPU
> buffer_head LRU caches will be pinned and thus cannot be migrated.
> This can prevent CMA allocations from succeeding, which are often used
> on platforms with co-processors
On Thu, 18 Mar 2021 10:00:17 -0600 Jens Axboe wrote:
> On 3/18/21 9:53 AM, Shakeel Butt wrote:
> > On Wed, Mar 17, 2021 at 3:30 PM Jens Axboe wrote:
> >>
> >> On 3/16/21 9:36 AM, Dan Schatzberg wrote:
> >>> No major changes, just rebasing and resubmitting
> >>
> >> Applied for 5.13, thanks.
>
On Mon, 15 Mar 2021 18:30:03 -0700 Arjun Roy wrote:
> From: Arjun Roy
>
> TCP zerocopy receive is used by high performance network applications
> to further scale. For RX zerocopy, the memory containing the network
> data filled by the network driver is directly mapped into the address
> space
On Wed, 10 Mar 2021 08:14:28 -0800 Minchan Kim wrote:
> LRU pagevec holds refcount of pages until the pagevec are drained.
> It could prevent migration since the refcount of the page is greater
> than the expection in migration logic. To mitigate the issue,
> callers of migrate_pages drains LRU
On Wed, 17 Mar 2021 16:23:48 +1000 Nicholas Piggin wrote:
>
> *** BLURB HERE ***
>
That's really not what it means ;)
Could we please get a nice description for the [0/n]? What's it all
about, what's the benefit, what are potential downsides.
And performance testing results! Because if it
On Wed, 17 Mar 2021 14:20:48 + Chen Jun wrote:
> On arm64, cat /sys/kernel/debug/page_owner
> All pages return the same stack
> stack_trace_save+0x4c/0x78
> register_early_stack+0x34/0x70
> init_page_owner+0x34/0x230
> page_ext_init+0x1bc/0x1dc
>
> The reason is arch_stack_walk save 2
On Wed, 17 Mar 2021 14:41:46 -0700 Brian Geffon wrote:
> Currently MREMAP_DONTUNMAP only accepts private anonymous mappings. This
> change will widen the support to include any mappings which are not
> VM_DONTEXPAND or VM_PFNMAP.
Please update changelog to explain why these two were omitted?
>
On Tue, 16 Mar 2021 03:15:05 + Yixun Lan wrote:
> This patch title is too obscure to parse, it should clearly reflect
> what's the changes doing here
Yes please ;) Otherwise Andrew has to madly grep around to try to figure out
what was Jiuyang Liu's "last patch"!
On Wed, 13 Jan 2021 13:17:30 -0800 Chris Goldsworthy
wrote:
> From: Laura Abbott
>
> When a buffer is added to the LRU list, a reference is taken which is
> not dropped until the buffer is evicted from the LRU list. This is the
> correct behavior, however this LRU reference will prevent the
On Sat, 13 Mar 2021 22:25:27 +0100 Rasmus Villemoes
wrote:
> Most of the boot process doesn't actually need anything from the
> initramfs, until of course PID1 is to be executed. So instead of doing
> the decompressing and populating of the initramfs synchronously in
> populate_rootfs() itself,
On Sun, 14 Mar 2021 04:11:55 + Matthew Wilcox wrote:
> On Sat, Mar 13, 2021 at 12:37:07PM -0800, Andrew Morton wrote:
> > On Fri, 5 Mar 2021 04:18:39 + "Matthew Wilcox (Oracle)"
> > wrote:
> >
> > > Allow page counters to be more readily modi
On Fri, 5 Mar 2021 04:18:37 + "Matthew Wilcox (Oracle)"
wrote:
> A struct folio refers to an entire (possibly compound) page. A function
> which takes a struct folio argument declares that it will operate on the
> entire compound page, not just PAGE_SIZE bytes. In return, the caller
>
On Fri, 5 Mar 2021 04:18:39 + "Matthew Wilcox (Oracle)"
wrote:
> Allow page counters to be more readily modified by callers which have
> a folio. Name these wrappers with 'stat' instead of 'state' as requested
> by Linus here:
>
On Fri, 5 Mar 2021 04:18:45 + "Matthew Wilcox (Oracle)"
wrote:
> folio_index() is the equivalent of page_index() for folios. folio_page()
> finds the page in a folio for a page cache index. folio_contains()
> tells you whether a folio contains a particular page cache index.
>
On Fri, 5 Mar 2021 04:18:36 + "Matthew Wilcox (Oracle)"
wrote:
> Our type system does not currently distinguish between tail pages and
> head or single pages. This is a problem because we call compound_head()
> multiple times (and the compiler cannot optimise it out), bloating the
>
On Fri, 12 Mar 2021 12:39:12 -0600 Jim Newsome wrote:
> On 3/12/21 12:22, Andrew Morton wrote:
> >
> > Could we please see some performance testing results to permit us to
> > evaluate the value of this change?
>
> Sure. I've been doing some ad-hoc measurements with
On Fri, 12 Mar 2021 11:38:55 -0600 Jim Newsome wrote:
> do_wait is an internal function used to implement waitpid, waitid,
> wait4, etc. To handle the general case, it does an O(n) linear scan of
> the thread group's children and tracees.
>
> This patch adds a special-case when waiting on a pid
On Thu, 11 Mar 2021 13:56:15 +0800 Yejune Deng wrote:
> refcount_t type should be used instead of atomic_t when the variable
> is used as a reference counter. This is because the implementation of
> refcount_t can prevent overflows and detect possible use-after-free.
The use of refcount_t comes
On Thu, 11 Mar 2021 18:14:19 + Joe LeVeque wrote:
> Is this all your looking for? If not, please let me know.
>
> > Signed-off-by: Joe LeVeque
Yes, thanks.
On Thu, 11 Mar 2021 09:32:45 +0800 Walter Wu wrote:
>
> Hi Andrew,
>
> I see my v4 patch is different in the next tree now. please see below
> information.
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=ebced5fb0ef969620ecdc4011f600f9e7c229a3c
> The different
On Wed, 10 Mar 2021 18:13:21 -0800 Mike Kravetz wrote:
> put_page does not correctly handle all calling contexts for hugetlb
> pages. This was recently discussed in the threads [1] and [2].
>
> free_huge_page is the routine called for the final put_page of huegtlb
> pages. Since at least the
On Thu, 4 Mar 2021 13:46:26 +0100 Paul Menzel wrote:
> From: Joe LeVeque
>
> The purpose is to notify the kernel module for fast reboot.
>
> Upstream a patch from the SONiC network operating system [1].
>
> [1]: https://github.com/Azure/sonic-linux-kernel/pull/46
>
> Signed-off-by: Paul
On Wed, 10 Mar 2021 13:31:17 -0800 Sean Christopherson
wrote:
> Invoke the MMU notifier's .invalidate_range_end() callbacks even if one
> of the .invalidate_range_start() callbacks failed. If there are multiple
> notifiers, the notifier that did not fail may have performed actions in
> its
rect to convert btrfs to
> zero_user().
>
> This series corrects this by lifting memzero_user(), converting it to
> kmap_local_page(), and then using it in btrfs.
This impacts btrfs more than MM. I suggest the btrfs developers grab
it, with my
Acked-by: Andrew Morton
On Tue, 9 Mar 2021 13:42:55 -0800 Kees Cook wrote:
> Choosing the initial state of static branches changes the assembly layout
> (if the condition is expected to be likely, inline, or unlikely, out of
> line via a jump). The _TRUE/_FALSE defines for CONFIG_INIT_ON_*_DEFAULT_ON
> were
On Wed, 10 Mar 2021 10:46:15 + Mel Gorman
wrote:
> This patch adds a new page allocator interface via alloc_pages_bulk,
> and __alloc_pages_bulk_nodemask. A caller requests a number of pages
> to be allocated and added to a list. They can be freed in bulk using
> free_pages_bulk().
Why am
On Wed, 10 Mar 2021 10:46:13 + Mel Gorman
wrote:
> This series introduces a bulk order-0 page allocator with sunrpc and
> the network page pool being the first users.
Right now, the [0/n] doesn't even tell us that it's a performance
patchset!
The whole point of this patchset appears to
On Wed, 10 Mar 2021 10:01:04 -0800 Minchan Kim wrote:
> Currently, debugging CMA allocation failures is quite limited.
> The most commong source of these failures seems to be page
> migration which doesn't provide any useful information on the
> reason of the failure by itself.
1 - 100 of 25528 matches
Mail list logo
