On Wed, 22 May 2024 16:38:01 -0400 Eric Chanudet wrote:
> x86_64 is already using the node's cpu as maximum threads. Make that the
> default for all archs setting DEFERRED_STRUCT_PAGE_INIT.
>
> This returns to the behavior prior making the function arch-specific
> with commit ecd096506922 ("mm:
On Mon, 15 Apr 2024 14:51:32 -0500 Maxwell Bland wrote:
> ptdump can now note non-leaf descriptor entries, a useful addition for
> debugging table descriptor permissions when working on related code
>
> Signed-off-by: Maxwell Bland
> ---
> arch/arm64/mm/ptdump.c | 6 --
>
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 Wed, 3 Apr 2024 16:37:58 +0800 Kefeng Wang
wrote:
> After VMA lock-based page fault handling enabled, if bad access met
> under per-vma lock, it will fallback to mmap_lock-based handling,
> so it leads to unnessary mmap lock and vma find again. A test from
> lmbench shows 34% improve after
On Thu, 28 Mar 2024 11:10:59 +0100 David Hildenbrand wrote:
> @Andrew, you properly adjusted the code to remove the
> gup_fast_folio_allowed() call instead of the folio_fast_pin_allowed()
> call, but
>
> (1) the commit subject
> (2) comment for gup_huge_pd()
>
> Still mention
On Wed, 27 Mar 2024 13:00:43 -0700 Samuel Holland
wrote:
> Now that all previously-supported architectures select
> ARCH_HAS_KERNEL_FPU_SUPPORT, this code can depend on that symbol instead
> of the existing list of architectures. It can also take advantage of the
> common kernel-mode FPU API
On Fri, 26 Jan 2024 14:44:51 +0800 Huang Shijie
wrote:
> During the kernel booting, the generic cpu_to_node() is called too early in
> arm64, powerpc and riscv when CONFIG_NUMA is enabled.
>
> There are at least four places in the common code where
> the generic cpu_to_node() is called before
On Thu, 21 Mar 2024 18:08:02 -0400 pet...@redhat.com wrote:
> From: Peter Xu
>
> Now follow_page() is ready to handle hugetlb pages in whatever form, and
> over all architectures. Switch to the generic code path.
>
> Time to retire hugetlb_follow_page_mask(), following the previous
>
On Thu, 22 Feb 2024 10:47:29 +0530 Hari Bathini wrote:
>
>
> On 22/02/24 2:27 am, Andrew Morton wrote:
> > On Wed, 21 Feb 2024 11:15:00 +0530 Hari Bathini
> > wrote:
> >
> >> On 04/02/24 8:56 am, Baoquan He wrote:
> >>>>> Hope Hari
On Wed, 21 Feb 2024 11:15:00 +0530 Hari Bathini wrote:
> On 04/02/24 8:56 am, Baoquan He wrote:
> >>> Hope Hari and Pingfan can help have a look, see if
> >>> it's doable. Now, I make it either have both kexec and crash enabled, or
> >>> disable both of them altogether.
> >>
> >> Sure. I will
On Wed, 21 Feb 2024 22:59:47 +0530 Sourabh Jain
wrote:
> > config ARCH_HAS_GENERIC_CRASHKERNEL_RESERVATION
> > - def_bool CRASH_CORE
> > + def_bool CRASH_RESEERVE
>
> %s/CRASH_RESEERVE/CRASH_RESERVE?
Yes, thanks, this has been addressed in a followon fixup patch
in the mm.git tree.
On Mon, 29 Jan 2024 13:43:39 +0530 "Aneesh Kumar K.V"
wrote:
> > return (pud_val(pud) & (_PAGE_PSE|_PAGE_DEVMAP)) == _PAGE_PSE;
> > }
> > #endif
> >
> > #ifdef CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD
> > static inline int pud_devmap(pud_t pud)
> > {
> > return !!(pud_val(pud)
On Mon, 22 Jan 2024 22:43:05 -0800 Suren Baghdasaryan wrote:
> The change [1] missed ARM architecture when fixing major fault accounting
> for page fault retry under per-VMA lock. Add missing code to fix ARM
> architecture fault accounting.
>
> [1] 46e714c729c8 ("arch/mm/fault: fix major fault
(cc Muchun)
On Wed, 10 Jan 2024 14:03:35 +0530 Donet Tom
wrote:
> The kernel sefltest mm/hugepage-vmemmap fails on architectures
> which has different page size other than 4K. In hugepage-vmemmap
> page size used is 4k so the pfn calculation will go wrong on systems
> which has different page
On Wed, 20 Dec 2023 12:22:29 +0800 Baoquan He wrote:
> Could you help fix the typo in subject?
>
> [PATCH v4 5/7] kexec_file, ricv: print out debugging message if required
>~~~ s/ricv/riscv/
I made that change.
On Fri, 01 Dec 2023 09:39:20 +1100 Michael Ellerman wrote:
> > I am still carrying this patch (it should probably go into the mm
> > tree). Is someone going to pick it up (assuming it is correct)?
>
> I applied it to my next a few days ago, but I must have forgotten to
> push. It's in there
On Fri, 1 Dec 2023 09:04:39 +1100 Stephen Rothwell
wrote:
> Hi all,
>
> > > diff --git a/arch/powerpc/mm/book3s64/pgtable.c
> > > b/arch/powerpc/mm/book3s64/pgtable.c
> > > index be229290a6a7..3438ab72c346 100644
> > > --- a/arch/powerpc/mm/book3s64/pgtable.c
> > > +++
On Thu, 2 Nov 2023 16:03:18 +0800 Baoquan He wrote:
> > > CONFIG_KEXEC_FILE, but still get purgatory code built in which is
> > > totally useless.
> > >
> > > Not sure if I think too much over this.
> >
> > I see your point here, and I would suggest changing the
> >
On Tue, 14 Nov 2023 17:16:57 +0800 Baoquan He wrote:
> This function, being a variant of walk_system_ram_res() introduced in
> commit 8c86e70acead ("resource: provide new functions to walk through
> resources"), walks through a list of all the resources of System RAM
> in reversed order, i.e.,
On Fri, 10 Nov 2023 02:22:27 + "Daniel Walker (danielwa)"
wrote:
> On Thu, Nov 09, 2023 at 05:51:42PM -0800, Andrew Morton wrote:
> > On Thu, 9 Nov 2023 17:38:04 -0800 Daniel Walker wrote:
> >
> > > This release is an up-rev of the v5 patches. No additio
On Thu, 9 Nov 2023 17:38:04 -0800 Daniel Walker wrote:
> This release is an up-rev of the v5 patches. No additional features have
> been added. Some changes were mode to function names and some changes to
> Kconfig dependencies. Also updated the config conversion for mips.
>
> There are a
On Sun, 08 Oct 2023 09:54:22 +1100 Michael Ellerman wrote:
> > I don't know why powerpc's PTE_INDEX_SIZE is variable.
>
> To allow a single vmlinux to boot using either the Hashed Page Table
> MMU, or Radix Tree MMU, which have different page table geometry.
>
> That's a pretty crucial feature
On Fri, 29 Sep 2023 12:44:15 +0100 Ryan Roberts wrote:
> In preparation for adding support for anonymous large folios that are
> smaller than the PMD-size, introduce 2 new sysfs files that will be used
> to control the new behaviours via the transparent_hugepage interface.
> For now, the kernel
On Thu, 21 Sep 2023 17:19:59 +0100 Ryan Roberts wrote:
> Hi All,
>
> This series fixes a bug in arm64's implementation of set_huge_pte_at(), which
> can result in an unprivileged user causing a kernel panic. The problem was
> triggered when running the new uffd poison mm selftest for HUGETLB
On Wed, 26 Jul 2023 10:59:32 +0530 Aneesh Kumar K V
wrote:
> On 7/26/23 12:59 AM, Andrew Morton wrote:
> > On Tue, 25 Jul 2023 00:37:46 +0530 "Aneesh Kumar K.V"
> > wrote:
> >
> >> This patch series implements changes required to support DAX vmemmap
On Tue, 25 Jul 2023 00:37:46 +0530 "Aneesh Kumar K.V"
wrote:
> This patch series implements changes required to support DAX vmemmap
> optimization for ppc64.
Do we have any measurements to help us understand the magnitude
of this optimization?
And any documentation which helps users
On Mon, 24 Jul 2023 23:59:27 +0530 "Aneesh Kumar K.V"
wrote:
> Please take this diff on top of this patch when adding this series to
> -mm .
"[10/13] powerpc/book3s64/vmemmap: Switch radix to use a different
vmemmap handling function" has a conflict with "mm: move
is_ioremap_addr() into new
On Fri, 21 Jul 2023 18:49:50 +0530 "Aneesh Kumar K.V"
wrote:
> Signed-off-by: Aneesh Kumar K.V
> ---
> This is dependent on patches posted at
> https://lore.kernel.org/linux-mm/20230718024409.95742-1-aneesh.ku...@linux.ibm.com/
It appears that the above-linked series is to be updated, so
On Tue, 18 Jul 2023 14:57:12 -0300 Jason Gunthorpe wrote:
> On Tue, Jul 18, 2023 at 05:56:15PM +1000, Alistair Popple wrote:
> > diff --git a/include/asm-generic/tlb.h b/include/asm-generic/tlb.h
> > index b466172..48c81b9 100644
> > --- a/include/asm-generic/tlb.h
> > +++
On Tue, 18 Jul 2023 17:56:17 +1000 Alistair Popple wrote:
> The arch_invalidate_secondary_tlbs() is an architecture specific mmu
> notifier used to keep the TLB of secondary MMUs such as an IOMMU in
> sync with the CPU page tables. Currently it is called from separate
> code paths to the main
On Sat, 8 Jul 2023 10:29:42 -0700 Linus Torvalds
wrote:
> On Sat, 8 Jul 2023 at 04:35, Thorsten Leemhuis
> wrote:
> >
> > The plan since early this week is to mark CONFIG_PER_VMA_LOCK as broken;
> > latest patch that does this is this one afaics:
>
> Bah.
>
> Both marking it as broken and
On Wed, 5 Jul 2023 10:51:57 +0200 "Linux regression tracking (Thorsten
Leemhuis)" wrote:
> >>> I'm in wait-a-few-days-mode on this. To see if we have a backportable
> >>> fix rather than disabling the feature in -stable.
>
> Andrew, how long will you remain in "wait-a-few-days-mode"? Given
On Tue, 4 Jul 2023 13:22:54 -0700 Suren Baghdasaryan wrote:
> On Tue, Jul 4, 2023 at 9:18 AM Andrew Morton
> wrote:
> >
> > On Tue, 4 Jul 2023 09:00:19 +0100 Greg KH
> > wrote:
> >
> > > > > > > Thanks! I'll investigate this later today. A
On Tue, 4 Jul 2023 09:00:19 +0100 Greg KH wrote:
> > > > > Thanks! I'll investigate this later today. After discussing with
> > > > > Andrew, we would like to disable CONFIG_PER_VMA_LOCK by default until
> > > > > the issue is fixed. I'll post a patch shortly.
> > > >
> > > > Posted at:
> > > >
On Sat, 24 Jun 2023 20:22:27 +0530 "Aneesh Kumar K.V"
wrote:
> > 28 files changed, 1032 insertions(+), 77 deletions(-)
> > create mode 100644 Documentation/powerpc/vmemmap_dedup.rst
> >
>
> Michael Ellerman merged some of the ppc64 patches. How do
> you like to merge the mm changes? Do you
On Thu, 22 Jun 2023 10:40:11 +0200 Petr Mladek wrote:
> On Wed 2023-06-21 16:48:19, Douglas Anderson wrote:
> > The powerpc architecture was the only one that defined
> > arch_trigger_cpumask_backtrace() in asm/nmi.h instead of
> > asm/irq.h. Move it to be consistent.
> >
> > This fixes compile
On Fri, 5 May 2023 16:02:17 + David Laight wrote:
> From: Michael Ellerman
> > Sent: 05 May 2023 04:51
> >
> > Since commit 1ba3cbf3ec3b ("mm: kfence: improve the performance of
> > __kfence_alloc() and __kfence_free()"), kfence reports failures in
> > random places at boot on big endian
On Wed, 12 Apr 2023 18:27:08 +0100 Catalin Marinas
wrote:
> > It sounds nice in theory. In practice. EXPERT hides too much. When you
> > flip expert, you expose over a 175ish new config options which are
> > hidden behind EXPERT. You don't have to know what you are doing just
> > with the
On Mon, 27 Feb 2023 10:47:27 +0100 Marco Elver wrote:
> With appropriate compiler support [1], KASAN builds use __asan prefixed
> meminstrinsics, and KASAN no longer overrides memcpy/memset/memmove.
>
> If compiler support is detected (CC_HAS_KASAN_MEMINTRINSIC_PREFIX),
> define memintrinsics
On Fri, 3 Feb 2023 17:18:37 +1000 Nicholas Piggin wrote:
> On a 16-socket 192-core POWER8 system, the context_switch1_threads
> benchmark from will-it-scale (see earlier changelog), upstream can
> achieve a rate of about 1 million context switches per second, due to
> contention on the mm
On Tue, 31 Jan 2023 13:08:19 -0800 Suren Baghdasaryan wrote:
> On Tue, Jan 31, 2023 at 12:54 PM Andrew Morton
> wrote:
> >
> > On Tue, 31 Jan 2023 10:54:22 -0800 Suren Baghdasaryan
> > wrote:
> >
> > > > > - vma->vm_flags &= ~VM_
On Tue, 31 Jan 2023 10:54:22 -0800 Suren Baghdasaryan wrote:
> > > - vma->vm_flags &= ~VM_MAYWRITE;
> > > + vm_flags_clear(vma, VM_MAYSHARE);
> > > }
> >
> > I think it should be:
> > s/VM_MAYSHARE/VM_MAYWRITE/
>
I added the fixup. Much better than
On Fri, 27 Jan 2023 11:40:37 -0800 Suren Baghdasaryan wrote:
> Per-vma locks idea that was discussed during SPF [1] discussion at LSF/MM
> last year [2], which concluded with suggestion that “a reader/writer
> semaphore could be put into the VMA itself; that would have the effect of
> using the
On Fri, 27 Jan 2023 09:27:08 +0100 Luca Ceresoli
wrote:
> > On Thu, 26 Jan 2023 16:22:05 +0100 Luca Ceresoli wrote:
> > > Fix typos and add the following to the scripts/spelling.txt:
> > >
> > > exsits||exists
> > >
> > > Signed-off-by: Luca Ceresoli
> >
> > You need to split this up
On Thu, 26 Jan 2023 08:04:47 +0100 Christophe Leroy
wrote:
> On powerpc64, you can build a kernel with KASAN as soon as you build it
> with RADIX MMU support. However if the CPU doesn't have RADIX MMU,
> KASAN isn't enabled at init and the following Oops is encountered.
Should we backport to
On Wed, 25 Jan 2023 21:07:57 +0200 Mike Rapoport wrote:
> Every architecture that supports FLATMEM memory model defines its own
> version of pfn_valid() that essentially compares a pfn to max_mapnr.
>
> Use mips/powerpc version implemented as static inline as a generic
> implementation of
On Wed, 25 Jan 2023 16:50:01 -0800 Suren Baghdasaryan wrote:
> On Wed, Jan 25, 2023 at 4:22 PM Andrew Morton
> wrote:
> >
> > On Wed, 25 Jan 2023 15:35:48 -0800 Suren Baghdasaryan
> > wrote:
> >
> > > Convert vma assignment in vm_area_dup() to a memcpy(
On Wed, 25 Jan 2023 15:35:49 -0800 Suren Baghdasaryan wrote:
> --- a/include/linux/mm_types.h
> +++ b/include/linux/mm_types.h
> @@ -491,7 +491,15 @@ struct vm_area_struct {
>* See vmf_insert_mixed_prot() for discussion.
>*/
> pgprot_t vm_page_prot;
> - unsigned long
On Wed, 25 Jan 2023 15:35:49 -0800 Suren Baghdasaryan wrote:
> vm_flags are among VMA attributes which affect decisions like VMA merging
> and splitting. Therefore all vm_flags modifications are performed after
> taking exclusive mmap_lock to prevent vm_flags updates racing with such
>
On Wed, 25 Jan 2023 15:35:48 -0800 Suren Baghdasaryan wrote:
> Convert vma assignment in vm_area_dup() to a memcpy() to prevent compiler
> errors when we add a const modifier to vma->vm_flags.
>
> ...
>
> --- a/kernel/fork.c
> +++ b/kernel/fork.c
> @@ -482,7 +482,7 @@ struct vm_area_struct
On Thu, 22 Dec 2022 12:46:16 +0100 Andrzej Hajda
wrote:
> Hi all,
>
> I hope there will be place for such tiny helper in kernel.
> Quick cocci analyze shows there is probably few thousands places
> where it could be useful.
So to clarify, the intent here is a simple readability cleanup for
On Thu, 17 Nov 2022 16:26:47 +0800 Yicong Yang wrote:
> From: Anshuman Khandual
>
> The entire scheme of deferred TLB flush in reclaim path rests on the
> fact that the cost to refill TLB entries is less than flushing out
> individual entries by sending IPI to remote CPUs. But architecture
>
On Mon, 28 Nov 2022 09:18:47 +0100 David Hildenbrand wrote:
> > Less chances of things going wrong that way.
> >
> > Just mention in the v2 cover letter that the first patch was added to
> > make it easy to backport that fix without being hampered by merge
> > conflicts if it was added after
On Wed, 7 Sep 2022 11:01:43 -0700 Yang Shi wrote:
> Since general RCU GUP fast was introduced in commit 2667f50e8b81 ("mm:
> introduce a general RCU get_user_pages_fast()"), a TLB flush is no longer
> sufficient to handle concurrent GUP-fast in all cases, it only handles
> traditional IPI-based
On Thu, 21 Jul 2022 20:55:09 +0100 Ben Dooks wrote:
> The setup_profiling_timer() is mostly un-implemented by many
> architectures. In many places it isn't guarded by CONFIG_PROFILE
> which is needed for it to be used. Make it a weak symbol in
> kernel/profile.c and remove the 'return -EINVAL'
On Mon, 11 Jul 2022 12:35:34 +0530 Anshuman Khandual
wrote:
> This series drops __SXXX/__PXXX macros from across platforms in the tree.
I've updated mm-unstable to this version, thanks. I skipped the added-to-mm
emails to avoid wearing out people's inboxes.
Reissuing a 26-patch series N
On Fri, 20 May 2022 14:25:05 -0500 "Eric W. Biederman"
wrote:
> > I am not strongly against taking off __weak, just wondering if there's
> > chance to fix it in recordmcount, and the cost comparing with kernel fix;
> > except of this issue, any other weakness of __weak. Noticed Andrew has
> >
On Thu, 19 May 2022 23:17:48 +0800 kernel test robot wrote:
> Hi "Naveen,
>
> I love your patch! Yet something to improve:
>
> [auto build test ERROR on f993aed406eaf968ba3867a76bb46c95336a33d0]
>
> url:
>
On Wed, 18 May 2022 23:48:28 +0530 "Naveen N. Rao"
wrote:
> Since commit d1bcae833b32f1 ("ELF: Don't generate unused section
> symbols") [1], binutils (v2.36+) started dropping section symbols that
> it thought were unused. This isn't an issue in general, but with
> kexec_file.c, gcc is
On Wed, 11 May 2022 09:19:17 +0800 kernel test robot wrote:
> Hi Baolin,
>
> I love your patch! Yet something to improve:
>
> [auto build test ERROR on akpm-mm/mm-everything]
> [cannot apply to hnaz-mm/master arm64/for-next/core linus/master v5.18-rc6]
> [If your patch is applied to the wrong
On Tue, 10 May 2022 16:17:39 -0700 Andrew Morton
wrote:
> > +
> > +static inline pte_t huge_ptep_clear_flush(struct vm_area_struct *vma,
> > + unsigned long addr, pte_t *ptep)
> > +{
> > + return ptep_get(ptep);
> &
On Tue, 10 May 2022 11:45:59 +0800 Baolin Wang
wrote:
> On some architectures (like ARM64), it can support CONT-PTE/PMD size
> hugetlb, which means it can support not only PMD/PUD size hugetlb:
> 2M and 1G, but also CONT-PTE/PMD size: 64K and 32M if a 4K page
> size specified.
>
> When
On Tue, 10 May 2022 11:45:57 +0800 Baolin Wang
wrote:
> Hi,
>
> Now migrating a hugetlb page or unmapping a poisoned hugetlb page, we'll
> use ptep_clear_flush() and set_pte_at() to nuke the page table entry
> and remap it, and this is incorrect for CONT-PTE or CONT-PMD size hugetlb
> page,
es-only mode.
If there's a case to be made that these patches are needed by 5.18
users then please let's make that case. Otherwise, this is 5.19-rc1 material.
And if it is indeed all 5.19-rc1 material, then please carry all four
in the powerpc tree with Acked-by: Andrew Morton
.
Also, [4/4] has
On Thu, 7 Apr 2022 16:02:44 +0530 Anshuman Khandual
wrote:
> protection_map[] is an array based construct that translates given vm_flags
> combination. This array contains page protection map, which is populated by
> the platform via [__S000 .. __S111] and [__P000 .. __P111] exported macros.
>
On Fri, 11 Mar 2022 15:26:42 +1100 Michael Ellerman wrote:
> > What will be the merge strategy ? I guess it's a bit late to get it
> > through powerpc tree, so I was just wondering whether we could get
> > patches 2 to 5 in mm this cycle, and the powerpc ones next cycle ?
>
> Yeah I didn't
On Thu, 17 Feb 2022 14:05:36 +0530 "Aneesh Kumar K.V"
wrote:
> Avoid code duplication by adding util.h. No functional change
> in this patch.
Sorry, but changes in linux-next have messed this patch up a bit more
than I'm prepared to fix. Could you please redo these two against
linux-next
On Fri, 10 Dec 2021 21:36:00 +0800 Tiezhu Yang wrote:
> In arch/*/kernel/crash_dump*.c, there exist similar code about
> copy_oldmem_page(), move copy_to() from vmcore.c to uaccess.h,
> and then we can use copy_to() to simplify the related code.
>
> ...
>
> --- a/fs/proc/vmcore.c
> +++
On Fri, 01 Oct 2021 17:14:41 +1000 Daniel Axtens wrote:
> > #ifdef __KERNEL__
> > +/*
> > + * Check if an address is part of freed initmem. After initmem is freed,
> > + * memory can be allocated from it, and such allocations would then have
> > + * addresses within the range [_stext, _end].
>
On Tue, 28 Sep 2021 09:15:35 +0200 Christophe Leroy
wrote:
> Commit 7a5da02de8d6 ("locking/lockdep: check for freed initmem in
> static_obj()") added arch_is_kernel_initmem_freed() which is supposed
> to report whether an object is part of already freed init memory.
>
> For the time being, the
On Tue, 27 Jul 2021 15:59:55 +0100 Christoph Hellwig wrote:
> On Tue, Jul 27, 2021 at 04:48:53PM +0200, Arnd Bergmann wrote:
> > Since these patches are now all that remains, it would be nice to
> > merge it all through Andrew's Linux-mm tree, which is already based
> > on top of linux-next.
>
On Fri, 25 Jun 2021 05:10:12 + (UTC) Christophe Leroy
wrote:
> Pagewalk ignores hugepd entries and walk down the tables
> as if it was traditionnal entries, leading to crazy result.
>
> Add walk_hugepd_range() and use it to walk hugepage tables.
More details, please? I assume "crazy
On Wed, 16 Jun 2021 10:22:39 +0530 "Aneesh Kumar K.V"
wrote:
> To avoid a race between rmap walk and mremap, mremap does take_rmap_locks().
> The lock was taken to ensure that rmap walk don't miss a page table entry due
> to
> PTE moves via move_pagetables(). The kernel does further
On Wed, 16 Jun 2021 10:22:33 +0530 "Aneesh Kumar K.V"
wrote:
> This patch series is split out series from [PATCH v7 00/11] Speedup mremap on
> ppc64
> (https://lore.kernel.org/linux-mm/20210607055131.156184-1-aneesh.ku...@linux.ibm.com)
> dropping ppc64 specific changes.
>
> This patchset is
On Tue, 8 Jun 2021 12:13:15 +0300 Mike Rapoport wrote:
> From: Mike Rapoport
>
> After removal of DISCINTIGMEM the NEED_MULTIPLE_NODES and NUMA
> configuration options are equivalent.
>
> Drop CONFIG_NEED_MULTIPLE_NODES and use CONFIG_NUMA instead.
>
> Done with
>
> $ sed -i
On Tue, 8 Jun 2021 22:24:32 +0800 Baoquan He wrote:
> On 06/08/21 at 06:33am, Pingfan Liu wrote:
> > As mentioned in kernel commit 1d50e5d0c505 ("crash_core, vmcoreinfo:
> > Append 'MAX_PHYSMEM_BITS' to vmcoreinfo"), SECTION_SIZE_BITS in the
> > formula:
> > #define SECTIONS_SHIFT
On Tue, 08 Jun 2021 11:39:56 +1000 Nicholas Piggin wrote:
> > Looks like a functional change. What's happening here?
>
> That's kthread_use_mm being clever about the lazy tlb mm. If it happened
> that the kthread had inherited a the lazy tlb mm that happens to be the
> one we want to use
On Sat, 5 Jun 2021 11:42:16 +1000 Nicholas Piggin wrote:
> On a 16-socket 192-core POWER8 system, a context switching benchmark
> with as many software threads as CPUs (so each switch will go in and
> out of idle), upstream can achieve a rate of about 1 million context
> switches per second.
On Sat, 5 Jun 2021 11:42:13 +1000 Nicholas Piggin wrote:
> Add explicit _lazy_tlb annotated functions for lazy mm refcounting.
> This makes lazy mm references more obvious, and allows explicit
> refcounting to be removed if it is not used.
>
> ...
>
> --- a/kernel/kthread.c
> +++
On Sat, 15 May 2021 09:35:25 -0700 Guenter Roeck wrote:
> >
> > #define __HAVE_ARCH_FLUSH_PMD_TLB_RANGE
> > static inline void flush_pmd_tlb_range(struct vm_area_struct *vma,
>
> >unsigned long start, unsigned long end)
> > +{
> > +
On Fri, 14 May 2021 11:08:53 + (UTC) Christophe Leroy
wrote:
> When PUD and/or PMD are folded, those functions are useless
> and we now have a stub in linux/pgtable.h
OK, help me out here please. What patch does this fix?
On Thu, 22 Apr 2021 11:13:23 +0530 "Aneesh Kumar K.V"
wrote:
> mremap HAVE_MOVE_PMD/PUD optimization time comparison for 1GB region:
> 1GB mremap - Source PTE-aligned, Destination PTE-aligned
> mremap time: 1127034ns
> 1GB mremap - Source PMD-aligned, Destination PMD-aligned
> mremap
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,
> > -
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 Mon, 15 Feb 2021 11:32:01 -0800 Daniel Gimpelevich
wrote:
> On Thu, 2019-03-21 at 15:15 -0700, Andrew Morton wrote:
> > On Thu, 21 Mar 2019 08:13:08 -0700 Daniel Walker wrote:
> > > On Wed, Mar 20, 2019 at 08:14:33PM -0700, Andrew Morton wrote:
> > > > The pa
On Wed, 3 Feb 2021 10:19:44 + (UTC) Christophe Leroy
wrote:
> Commit 83d116c53058 ("mm: fix double page fault on arm64 if PTE_AF
> is cleared") introduced arch_faults_on_old_pte() helper to identify
> platforms that don't set page access bit in HW and require a page
> fault to set it.
>
>
On Fri, 22 Jan 2021 01:37:14 -0300 Thiago Jung Bauermann
wrote:
> Mike Rapoport writes:
>
> > > Signed-off-by: Roman Gushchin
> >
> > Reviewed-by: Mike Rapoport
>
> I've seen a couple of spurious triggers of the WARN_ONCE() removed by this
> patch. This happens on some ppc64le bare metal
On Wed, 14 Oct 2020 08:45:16 +0530 "Aneesh Kumar K.V"
wrote:
> > Against mm-debug_vm_pgtable-avoid-none-pte-in-pte_clear_test.patch:
> >
> > https://lkml.kernel.org/r/87zh5wx51b@linux.ibm.com
>
>
> yes this one we should get fixed. I was hoping someone familiar with
> Riscv pte updates
On Wed, 2 Sep 2020 17:12:09 +0530 "Aneesh Kumar K.V"
wrote:
> This patch series includes fixes for debug_vm_pgtable test code so that
> they follow page table updates rules correctly. The first two patches
> introduce
> changes w.r.t ppc64. The patches are included in this series for
>
On Wed, 2 Sep 2020 11:09:11 +0200 Laurent Dufour wrote:
> register_mem_sect_under_nodem() is checking the memory block's node id only
> if the system state is "SYSTEM_BOOTING". On PowerPC, the memory blocks are
> registered while the system state is "SYSTEM_SCHEDULING", the one before
>
On Sat, 22 Aug 2020 01:12:05 +1000 Nicholas Piggin wrote:
> vmalloc_to_page returns NULL for addresses mapped by larger pages[*].
> Whether or not a vmap is huge depends on the architecture details,
> alignments, boot options, etc., which the caller can not be expected
> to know. Therefore
On Sat, 22 Aug 2020 01:12:10 +1000 Nicholas Piggin wrote:
> #ifdef CONFIG_HAVE_ARCH_HUGE_VMAP
> -bool arch_vmap_p4d_supported(pgprot_t prot);
> -bool arch_vmap_pud_supported(pgprot_t prot);
> -bool arch_vmap_pmd_supported(pgprot_t prot);
> +static inline bool arch_vmap_p4d_supported(pgprot_t
On Sat, 22 Aug 2020 01:12:09 +1000 Nicholas Piggin wrote:
> This changes the awkward approach where architectures provide init
> functions to determine which levels they can provide large mappings for,
> to one where the arch is queried for each call.
>
> This removes code and indirection, and
On Tue, 18 Aug 2020 18:16:26 +0300 Mike Rapoport wrote:
> From: Mike Rapoport
>
> The only user of memblock_dbg() outside memblock was s390 setup code and it
> is converted to use pr_debug() instead.
> This allows to stop exposing memblock_debug and memblock_dbg() to the rest
> of the kernel.
On Fri, 3 Jul 2020 18:28:23 +0530 Srikar Dronamraju
wrote:
> > The memory hotplug changes that somehow because you can hotremove numa
> > nodes and therefore make the nodemask sparse but that is not a common
> > case. I am not sure what would happen if a completely new node was added
> > and
On Tue, 9 Jun 2020 14:05:33 +0200 Joerg Roedel wrote:
> From: Joerg Roedel
>
> The functions are only used in two source files, so there is no need
> for them to be in the global header. Move them to the new
> header and include it only where needed.
>
> ...
>
> new file mode 100644
>
On Mon, 15 Jun 2020 12:22:29 +0300 Mike Rapoport wrote:
> From: Mike Rapoport
>
> The pte_update() implementation for PPC_8xx unfolds page table from the PGD
> level to access a PMD entry. Since 8xx has only 2-level page table this can
> be simplified with pmd_off() shortcut.
>
> Replace
On Tue, 16 Jun 2020 11:43:11 -0400 Waiman Long wrote:
> As said by Linus:
>
> A symmetric naming is only helpful if it implies symmetries in use.
> Otherwise it's actively misleading.
>
> In "kzalloc()", the z is meaningful and an important part of what the
> caller wants.
>
> In
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
> >
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
1 - 100 of 581 matches
Mail list logo
