Re: [PATCH v2 07/12] s390: add pte_free_defer() for pgtables sharing page

On Wed, 5 Jul 2023 17:52:40 -0700 (PDT) Hugh Dickins wrote: > On Wed, 5 Jul 2023, Alexander Gordeev wrote: > > On Sat, Jul 01, 2023 at 09:32:38PM -0700, Hugh Dickins wrote: > > > On Thu, 29 Jun 2023, Hugh Dickins wrote: > > > > Hi Hugh, > > > > ... > > > > > +#ifdef

Re: [PATCH v2 07/12] s390: add pte_free_defer() for pgtables sharing page

On Wed, 5 Jul 2023 18:20:21 -0700 (PDT) Hugh Dickins wrote: > On Wed, 5 Jul 2023, Gerald Schaefer wrote: > > On Tue, 4 Jul 2023 10:03:57 -0700 (PDT) > > Hugh Dickins wrote: > > > On Tue, 4 Jul 2023, Gerald Schaefer wrote: > > > > On Sat, 1 Jul 2023 21:32

Re: [PATCH v2 07/12] s390: add pte_free_defer() for pgtables sharing page

On Tue, 4 Jul 2023 10:03:57 -0700 (PDT) Hugh Dickins wrote: > On Tue, 4 Jul 2023, Gerald Schaefer wrote: > > On Sat, 1 Jul 2023 21:32:38 -0700 (PDT) > > Hugh Dickins wrote: > > > On Thu, 29 Jun 2023, Hugh Dickins wrote: > > > > > > > > I've

Re: [PATCH v2 07/12] s390: add pte_free_defer() for pgtables sharing page

On Sat, 1 Jul 2023 21:32:38 -0700 (PDT) Hugh Dickins wrote: > On Thu, 29 Jun 2023, Hugh Dickins wrote: > > > > I've grown to dislike the (ab)use of pt_frag_refcount even more, to the > > extent that I've not even tried to verify it; but I think I do get the > > point now, that we need further

Re: [PATCH v2 07/12] s390: add pte_free_defer() for pgtables sharing page

On Thu, 29 Jun 2023 23:00:07 -0700 (PDT) Hugh Dickins wrote: > On Thu, 29 Jun 2023, Gerald Schaefer wrote: > > On Thu, 29 Jun 2023 12:22:24 -0300 > > Jason Gunthorpe wrote: > > > On Wed, Jun 28, 2023 at 10:08:08PM -0700, Hugh Dickins wrote: > > > > On Wed

Re: [PATCH v2 07/12] s390: add pte_free_defer() for pgtables sharing page

On Thu, 29 Jun 2023 12:22:24 -0300 Jason Gunthorpe wrote: > On Wed, Jun 28, 2023 at 10:08:08PM -0700, Hugh Dickins wrote: > > On Wed, 28 Jun 2023, Gerald Schaefer wrote: > > > > > > As discussed in the other thread, we would rather go with less complexit

Re: [PATCH v2 07/12] s390: add pte_free_defer() for pgtables sharing page

On Thu, 29 Jun 2023 15:59:07 +0200 Alexander Gordeev wrote: > On Wed, Jun 28, 2023 at 09:16:24PM +0200, Gerald Schaefer wrote: > > On Tue, 20 Jun 2023 00:51:19 -0700 (PDT) > > Hugh Dickins wrote: > > Hi Gerald, Hugh! > > ... > > @@ -407,6 +445,88 @@ voi

Re: [PATCH v2 07/12] s390: add pte_free_defer() for pgtables sharing page

ng back unallocated fragments to the list in pte_free_defer() can result in wasting some amount of memory for pagetables, depending on how long the allocated fragment will stay in use. In practice, this effect is expected to be insignificant, and not justify a far more complex approach, which might allow

Re: [PATCH 07/12] s390: add pte_free_defer(), with use of mmdrop_async()

On Wed, 7 Jun 2023 20:35:05 -0700 (PDT) Hugh Dickins wrote: > On Tue, 6 Jun 2023, Gerald Schaefer wrote: > > On Mon, 5 Jun 2023 22:11:52 -0700 (PDT) > > Hugh Dickins wrote: > > > On Thu, 1 Jun 2023 15:57:51 +0200 > > > Gerald Schaefer wrote: > >

Re: [PATCH 07/12] s390: add pte_free_defer(), with use of mmdrop_async()

t; - list_add_tail(>lru, >context.pgtable_list); > - else > - list_del(>lru); > + if (mask & 0x03U) { > + listed = (struct list_head *)table; > + list_add_tail(listed, >context.pgtable_list); > + } else { > + /* > + * Get address of the other page table sharing the page. > + * There are sure to be MUCH better ways to do all this! > + * But I'm rushing, and trying to keep to the obvious. > + */ > + listed = (struct list_head *)(table + PTRS_PER_PTE); > + if (virt_to_page(listed) != page) { > + /* sizeof(*listed) is twice sizeof(*table) */ > + listed -= PTRS_PER_PTE; > + } Same as above. > + list_del(listed); > + set_pte((pte_t *)>next, __pte(_PAGE_INVALID)); > + set_pte((pte_t *)>prev, __pte(_PAGE_INVALID)); > + } > spin_unlock_bh(>context.lock); > table = (unsigned long *) ((unsigned long) table | (0x01U << bit)); > tlb_remove_table(tlb, table); Reviewed-by: Gerald Schaefer

Re: [PATCH 05/12] powerpc: add pte_free_defer() for pgtables sharing page

On Mon, 29 May 2023 07:36:40 -0700 (PDT) Hugh Dickins wrote: > On Mon, 29 May 2023, Matthew Wilcox wrote: > > On Sun, May 28, 2023 at 11:20:21PM -0700, Hugh Dickins wrote: > > > +void pte_free_defer(struct mm_struct *mm, pgtable_t pgtable) > > > +{ > > > + struct page *page; > > > + > > > +

Re: [PATCH v3 03/34] s390: Use pt_frag_refcount for pagetables

On Wed, 31 May 2023 14:30:01 -0700 "Vishal Moola (Oracle)" wrote: > s390 currently uses _refcount to identify fragmented page tables. > The page table struct already has a member pt_frag_refcount used by > powerpc, so have s390 use that instead of the _refcount field as well. > This improves

Re: [PATCH] mm: add PTE pointer parameter to flush_tlb_fix_spurious_fault()

On Mon, 6 Mar 2023 17:06:44 + Catalin Marinas wrote: > On Mon, Mar 06, 2023 at 05:15:48PM +0100, Gerald Schaefer wrote: > > diff --git a/arch/arm64/include/asm/pgtable.h > > b/arch/arm64/include/asm/pgtable.h > > index b6ba466e2e8a..0bd18de9fd97 100644 > > -

[PATCH] mm: add PTE pointer parameter to flush_tlb_fix_spurious_fault()

with private flush_tlb_fix_spurious_fault() implementations need to be made aware of the new parameter. Reviewed-by: Alexander Gordeev Signed-off-by: Gerald Schaefer --- arch/arm64/include/asm/pgtable.h | 2 +- arch/mips/include/asm/pgtable.h | 3 ++- arch/powerpc/include/asm

Re: [PATCH 3/3] mm: rmap: Fix CONT-PTE/PMD size hugetlb issue when unmapping

On Tue, 3 May 2022 10:19:46 +0800 Baolin Wang wrote: > > > On 5/2/2022 10:02 PM, Gerald Schaefer wrote: > > On Sat, 30 Apr 2022 11:22:33 +0800 > > Baolin Wang wrote: > > > >> > >> > >> On 4/30/2022 4:02 AM, Gerald Schaefer wrote: >

Re: [PATCH 3/3] mm: rmap: Fix CONT-PTE/PMD size hugetlb issue when unmapping

On Sat, 30 Apr 2022 11:22:33 +0800 Baolin Wang wrote: > > > On 4/30/2022 4:02 AM, Gerald Schaefer wrote: > > On Fri, 29 Apr 2022 16:14:43 +0800 > > Baolin Wang wrote: > > > >> On some architectures (like ARM64), it can support CONT-PTE/PMD size >

Re: [PATCH 3/3] mm: rmap: Fix CONT-PTE/PMD size hugetlb issue when unmapping

On Fri, 29 Apr 2022 16:14:43 +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

Re: [PATCH v2 6/8] s390/pgtable: support __HAVE_ARCH_PTE_SWP_EXCLUSIVE

55|55566|66| > * |0123456789012345678901234567890123456789012345678901|23456|78901|23| > * > * Bits 0-51 store the offset. > + * Bit 52 (E) is used to remember PG_anon_exclusive. > * Bits 57-61 store the type. > * Bit 62 (S) is used for softdirty tracking. > - * Bits 52, 55 and 56 (X) are unused. > + * Bits 55 and 56 (X) are unused. > */ > > #define __SWP_OFFSET_MASK((1UL << 52) - 1) Thanks David! Reviewed-by: Gerald Schaefer

Re: [PATCH v2 5/8] s390/pgtable: cleanup description of swp pte layout

4455|5|55566|66| > * |0123456789012345678901234567890123456789012345678901|23456|78901|23| > + * > + * Bits 0-51 store the offset. > + * Bits 57-61 store the type. > + * Bit 62 (S) is used for softdirty tracking. > + * Bits 52, 55 and 56 (X) are unused. > */ > > #define __SWP_OFFSET_MASK((1UL << 52) - 1) Thanks David! Reviewed-by: Gerald Schaefer

Re: [PATCH v1 5/7] s390/pgtable: support __HAVE_ARCH_PTE_SWP_EXCLUSIVE

On Wed, 16 Mar 2022 14:01:07 +0100 Christian Borntraeger wrote: > > > Am 16.03.22 um 11:56 schrieb Gerald Schaefer: > > On Tue, 15 Mar 2022 18:12:16 +0100 > > David Hildenbrand wrote: > > > >> On 15.03.22 17:58, David Hildenbrand wrote: > >>> &

Re: [PATCH v1 5/7] s390/pgtable: support __HAVE_ARCH_PTE_SWP_EXCLUSIVE

On Tue, 15 Mar 2022 18:12:16 +0100 David Hildenbrand wrote: > On 15.03.22 17:58, David Hildenbrand wrote: > > > >>> This would mean that it is not OK to have bit 52 not zero for swap PTEs. > >>> But if I read the POP correctly, all bits except for the DAT-protection > >>> would be ignored for

Re: [PATCH v1 5/7] s390/pgtable: support __HAVE_ARCH_PTE_SWP_EXCLUSIVE

On Tue, 15 Mar 2022 15:18:35 +0100 David Hildenbrand wrote: > Let's steal one bit from the offset. While at it, document the meaning > of bit 62 for swap ptes. You define _PAGE_SWP_EXCLUSIVE as _PAGE_LARGE, which is bit 52, and this is not part of the swap pte offset IIUC. So stealing any bit

Re: Freeing page tables through RCU

On Thu, 25 Feb 2021 20:58:20 + Matthew Wilcox wrote: > In order to walk the page tables without the mmap semaphore, it must > be possible to prevent them from being freed and reused (eg if munmap() > races with viewing /proc/$pid/smaps). > > There is various commentary within the mm on how

Re: [RFC PATCH v2 1/3] mm/gup: fix gup_fast with dynamic page table folding

On Thu, 10 Sep 2020 11:33:17 -0700 Linus Torvalds wrote: > On Thu, Sep 10, 2020 at 11:13 AM Jason Gunthorpe wrote: > > > > So.. To change away from the stack option I think we'd have to pass > > the READ_ONCE value to pXX_offset() as an extra argument instead of it > > derefing the pointer

Re: [RFC PATCH v2 1/3] mm/gup: fix gup_fast with dynamic page table folding

On Thu, 10 Sep 2020 10:02:33 -0300 Jason Gunthorpe wrote: > On Thu, Sep 10, 2020 at 11:39:25AM +0200, Alexander Gordeev wrote: > > > As Gerald mentioned, it is very difficult to explain in a clear way. > > Hopefully, one could make sense ot of it. > > I would say the page table API requires

Re: [RFC PATCH v2 1/3] mm/gup: fix gup_fast with dynamic page table folding

On Thu, 10 Sep 2020 12:10:26 -0300 Jason Gunthorpe wrote: > On Thu, Sep 10, 2020 at 03:28:03PM +0200, Gerald Schaefer wrote: > > On Thu, 10 Sep 2020 10:02:33 -0300 > > Jason Gunthorpe wrote: > > > > > On Thu, Sep 10, 2020 at 11:39:25AM

Re: [RFC PATCH v2 1/3] mm/gup: fix gup_fast with dynamic page table folding

On Thu, 10 Sep 2020 10:02:33 -0300 Jason Gunthorpe wrote: > On Thu, Sep 10, 2020 at 11:39:25AM +0200, Alexander Gordeev wrote: > > > As Gerald mentioned, it is very difficult to explain in a clear way. > > Hopefully, one could make sense ot of it. > > I would say the page table API requires

Re: [RFC PATCH v2 1/3] mm/gup: fix gup_fast with dynamic page table folding

On Wed, 9 Sep 2020 15:03:24 -0300 Jason Gunthorpe wrote: > On Wed, Sep 09, 2020 at 07:25:34PM +0200, Gerald Schaefer wrote: > > I actually had to draw myself a picture to get some hold of > > this, or rather a walk-through with a certain pud-crossing > > range in a fo

Re: [RFC PATCH v2 1/3] mm/gup: fix gup_fast with dynamic page table folding

On Wed, 9 Sep 2020 09:18:46 -0700 Dave Hansen wrote: > On 9/9/20 5:29 AM, Gerald Schaefer wrote: > > This only works well as long there are real pagetable pointers involved, > > that can also be used for iteration. For gup_fast, or any other future > > pagetable walkers usin

Re: [RFC PATCH v2 0/3] mm/gup: fix gup_fast with dynamic page table folding

On Tue, 8 Sep 2020 19:36:50 +0200 Gerald Schaefer wrote: [..] > > It seems now that the generalization is very well accepted so far, > apart from some apparent issues on arm. Also, merging 2 + 3 and > putting them first seems to be acceptable, so we could do t

Re: [RFC PATCH v2 1/3] mm/gup: fix gup_fast with dynamic page table folding

On Tue, 8 Sep 2020 07:30:50 -0700 Dave Hansen wrote: > On 9/7/20 11:00 AM, Gerald Schaefer wrote: > > Commit 1a42010cdc26 ("s390/mm: convert to the generic get_user_pages_fast > > code") introduced a subtle but severe bug on s390 with gup_fast, due to > > dynamic

Re: [PATCH v4 00/13] mm/debug_vm_pgtable fixes

On Wed, 9 Sep 2020 13:38:25 +0530 Anshuman Khandual wrote: > > > On 09/04/2020 08:56 PM, Gerald Schaefer wrote: > > On Fri, 4 Sep 2020 12:18:05 +0530 > > Anshuman Khandual wrote: > > > >> > >> > >> On 09/02/2020 05:12 PM, Aneesh K

Re: [PATCH v4 00/13] mm/debug_vm_pgtable fixes

On Wed, 09 Sep 2020 11:38:39 +0530 "Aneesh Kumar K.V" wrote: > Gerald Schaefer writes: > > > On Fri, 4 Sep 2020 18:01:15 +0200 > > Gerald Schaefer wrote: > > > > [...] > >> > >> BTW2, a quick test with this change (so far) made the

Re: [PATCH v4 00/13] mm/debug_vm_pgtable fixes

On Wed, 9 Sep 2020 13:45:48 +0530 Anshuman Khandual wrote: [...] > > > > That would more match the "pte_t pointer" usage for hugetlb code, > > i.e. just cast a pmd_t pointer to it. Also changed to pmd_aligned, > > but I think the root cause is the pte_t pointer. > > Ideally, the pte_t pointer

Re: [RFC PATCH v2 1/3] mm/gup: fix gup_fast with dynamic page table folding

On Tue, 8 Sep 2020 07:30:50 -0700 Dave Hansen wrote: > On 9/7/20 11:00 AM, Gerald Schaefer wrote: > > Commit 1a42010cdc26 ("s390/mm: convert to the generic get_user_pages_fast > > code") introduced a subtle but severe bug on s390 with gup_fast, due to > > dynamic

Re: [RFC PATCH v2 0/3] mm/gup: fix gup_fast with dynamic page table folding

On Tue, 8 Sep 2020 07:22:39 +0200 Christophe Leroy wrote: > > > Le 07/09/2020 à 22:12, Mike Rapoport a écrit : > > On Mon, Sep 07, 2020 at 08:00:55PM +0200, Gerald Schaefer wrote: > >> This is v2 of an RFC previously discussed here: > >> https://lore.kern

Re: [PATCH v4 00/13] mm/debug_vm_pgtable fixes

On Fri, 4 Sep 2020 18:01:15 +0200 Gerald Schaefer wrote: [...] > > BTW2, a quick test with this change (so far) made the issues on s390 > go away: > > @@ -1069,7 +1074,7 @@ static int __init debug_vm_pgtable(void) > spin_unlock(ptl); > > #ifn

Re: [RFC PATCH v2 1/3] mm/gup: fix gup_fast with dynamic page table folding

On Tue, 8 Sep 2020 14:40:10 +0200 Christophe Leroy wrote: > > > Le 08/09/2020 à 14:09, Christian Borntraeger a écrit : > > > > > > On 08.09.20 07:06, Christophe Leroy wrote: > >> > >> > >> Le 07/09/2020 à 20:00, Gerald Schaefer a écr

[RFC PATCH v2 0/3] mm/gup: fix gup_fast with dynamic page table folding

This is v2 of an RFC previously discussed here: https://lore.kernel.org/lkml/20200828140314.8556-1-gerald.schae...@linux.ibm.com/ Patch 1 is a fix for a regression in gup_fast on s390, after our conversion to common gup_fast code. It will introduce special helper functions pXd_addr_end_folded(),

[RFC PATCH v2 2/3] mm: make pXd_addr_end() functions page-table entry aware

Signed-off-by: Gerald Schaefer --- arch/arm/include/asm/pgtable-2level.h| 2 +- arch/arm/mm/idmap.c | 6 ++-- arch/arm/mm/mmu.c| 8 ++--- arch/arm64/kernel/hibernate.c| 16 ++ arch/arm64/kvm/mmu.c | 16

[RFC PATCH v2 1/3] mm/gup: fix gup_fast with dynamic page table folding

hitectures introduced. Fixes: 1a42010cdc26 ("s390/mm: convert to the generic get_user_pages_fast code") Cc: # 5.2+ Reviewed-by: Gerald Schaefer Signed-off-by: Alexander Gordeev Signed-off-by: Gerald Schaefer --- arch/s390/include/asm/pgtable.h | 42 +

[RFC PATCH v2 3/3] mm: make generic pXd_addr_end() macros inline functions

subtle bugs. Signed-off-by: Alexander Gordeev Signed-off-by: Gerald Schaefer --- include/linux/pgtable.h | 36 1 file changed, 20 insertions(+), 16 deletions(-) diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h index 67ebc22cf83d..d9e7d16c2263

Re: [PATCH v4 00/13] mm/debug_vm_pgtable fixes

On Fri, 4 Sep 2020 18:01:15 +0200 Gerald Schaefer wrote: > On Fri, 4 Sep 2020 17:26:47 +0200 > Gerald Schaefer wrote: > > > On Fri, 4 Sep 2020 12:18:05 +0530 > > Anshuman Khandual wrote: > > > > > > > > > > > On 09/02/2020 05:12

Re: [PATCH v4 00/13] mm/debug_vm_pgtable fixes

On Fri, 4 Sep 2020 17:26:47 +0200 Gerald Schaefer wrote: > On Fri, 4 Sep 2020 12:18:05 +0530 > Anshuman Khandual wrote: > > > > > > > On 09/02/2020 05:12 PM, Aneesh Kumar K.V wrote: > > > This patch series includes fixes for debug_vm_pgtable test code

Re: [PATCH v4 00/13] mm/debug_vm_pgtable fixes

On Fri, 4 Sep 2020 12:18:05 +0530 Anshuman Khandual wrote: > > > On 09/02/2020 05:12 PM, 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

Re: [PATCH V3 0/4] mm/debug_vm_pgtable: Add some more tests

On Wed, 24 Jun 2020 13:05:39 +0200 Alexander Gordeev wrote: > On Wed, Jun 24, 2020 at 08:43:10AM +0530, Anshuman Khandual wrote: > > [...] > > > Hello Gerald/Christophe/Vineet, > > > > It would be really great if you could give this series a quick test > > on s390/ppc/arc platforms

Re: [PATCH v3 0/4] Clean up hugetlb boot command line processing

arch/x86/mm/hugetlbpage.c | 23 +-- > include/linux/hugetlb.h | 2 +- > mm/hugetlb.c | 190 +++--- > 10 files changed, 271 insertions(+), 170 deletions(-) > Looks good and works fine for s390, thanks for cleaning up! Acked-by: Gerald Schaefer # s390

Re: [PATCH V2 0/3] mm/debug: Add more arch page table helper tests

On Wed, 8 Apr 2020 12:41:51 +0530 Anshuman Khandual wrote: [...] > > > >> > >> Some thing like this instead. > >> > >> pte_t pte = READ_ONCE(*ptep); > >> pte = pte_mkhuge(__pte((pte_val(pte) | RANDOM_ORVALUE) & PMD_MASK)); > >> > >> We cannot use mk_pte_phys() as it is defined only on some

Re: [PATCH V2 0/3] mm/debug: Add more arch page table helper tests

On Sun, 5 Apr 2020 17:58:14 +0530 Anshuman Khandual wrote: [...] > > > > Could be fixed like this (the first de-reference is a bit special, > > because at that point *ptep does not really point to a large (pmd) entry > > yet, it is initially an invalid pte entry, which breaks our

Re: [PATCH V2 0/3] mm/debug: Add more arch page table helper tests

On Tue, 24 Mar 2020 10:52:52 +0530 Anshuman Khandual wrote: > This series adds more arch page table helper tests. The new tests here are > either related to core memory functions and advanced arch pgtable helpers. > This also creates a documentation file enlisting all expected semantics as >

Re: [PATCH V12] mm/debug: Add tests validating architecture page table helpers

On Wed, 12 Feb 2020 15:12:54 +0530 Anshuman Khandual wrote: > >> +/* > >> + * On s390 platform, the lower 12 bits are used to identify given page > >> table > >> + * entry type and for other arch specific requirements. But these bits > >> might > >> + * affect the ability to clear entries with

Re: [PATCH V12] mm/debug: Add tests validating architecture page table helpers

On Mon, 27 Jan 2020 22:33:08 -0500 Qian Cai wrote: > > > >> Did those tests ever find any regression or this is almost only useful for > >> new > > > > The test has already found problems with s390 page table helpers. > > Hmm, that is pretty weak where s390 is not even official supported

Re: [PATCH V12] mm/debug: Add tests validating architecture page table helpers

ing boot. Any non conformity here will > be reported as an warning which would need to be fixed. This test will help > catch any changes to the agreed upon semantics expected from generic MM and > enable platforms to accommodate it thereafter. > [...] > > Tested-by: Christop

Re: [PATCH V8] mm/debug: Add tests validating architecture page table helpers

On Mon, 28 Oct 2019 10:59:22 +0530 Anshuman Khandual wrote: > This adds tests which will validate architecture page table helpers and > other accessors in their compliance with expected generic MM semantics. > This will help various architectures in validating changes to existing > page table

Re: [PATCH V2 2/2] mm/pgtable/debug: Add test validating architecture page table helpers

On Wed, 18 Sep 2019 18:26:03 +0200 Christophe Leroy wrote: [..] > My suggestion was not to completely drop the #ifdef but to do like you > did in pgd_clear_tests() for instance, ie to add the following test on > top of the function: > > if (mm_pud_folded(mm) ||

Re: [PATCH 1/1] mm/pgtable/debug: Add test validating architecture page table helpers

On Mon, 9 Sep 2019 11:56:50 +0530 Anshuman Khandual wrote: [..] > > > > Hmm, I simply used this on my system to make pud_clear_tests() work, not > > sure if it works on all archs: > > > > pud_val(*pudp) |= RANDOM_NZVALUE; > > Which compiles on arm64 but then fails on x86 because of the way

Re: [PATCH 1/1] mm/pgtable/debug: Add test validating architecture page table helpers

On Fri, 6 Sep 2019 11:58:59 +0530 Anshuman Khandual wrote: > On 09/05/2019 10:36 PM, Gerald Schaefer wrote: > > On Thu, 5 Sep 2019 14:48:14 +0530 > > Anshuman Khandual wrote: > > > >>> [...] > >>>> + > >>>> +#if !def

Re: [PATCH 1/1] mm/pgtable/debug: Add test validating architecture page table helpers

On Thu, 5 Sep 2019 14:48:14 +0530 Anshuman Khandual wrote: > > [...] > >> + > >> +#if !defined(__PAGETABLE_PMD_FOLDED) && !defined(__ARCH_HAS_4LEVEL_HACK) > >> +static void pud_clear_tests(pud_t *pudp) > >> +{ > >> + memset(pudp, RANDOM_NZVALUE, sizeof(pud_t)); > >> + pud_clear(pudp); > >> +

Re: [PATCH 1/1] mm/pgtable/debug: Add test validating architecture page table helpers

On Tue, 3 Sep 2019 13:31:46 +0530 Anshuman Khandual wrote: > This adds a test module which will validate architecture page table helpers > and accessors regarding compliance with generic MM semantics expectations. > This will help various architectures in validating changes to the existing >

Re: [RFC PATCH 0/9] Enable THP migration for all possible architectures

On Thu, 26 Apr 2018 10:27:55 -0400 Zi Yan wrote: > From: Zi Yan > > Hi all, > > THP migration is only enabled on x86_64 with a special > ARCH_ENABLE_THP_MIGRATION macro. This patchset enables THP migration for > all architectures that uses transparent

Re: [PATCH 19/44] s390: implement ->mapping_error

> > Signed-off-by: Christoph Hellwig <h...@lst.de> Acked-by: Gerald Schaefer <gerald.schae...@de.ibm.com>

Re: [BUG] random kernel crashes after THP rework on s390 (maybe also on PowerPC and ARM)

On Tue, 23 Feb 2016 22:33:45 +0300 "Kirill A. Shutemov" <kir...@shutemov.name> wrote: > On Tue, Feb 23, 2016 at 07:19:07PM +0100, Gerald Schaefer wrote: > > I'll check with Martin, maybe it is actually trivial, then we can > > do a quick test it to rule that

Re: [BUG] random kernel crashes after THP rework on s390 (maybe also on PowerPC and ARM)

On Tue, 23 Feb 2016 13:32:21 +0300 "Kirill A. Shutemov" <kir...@shutemov.name> wrote: > On Fri, Feb 12, 2016 at 06:16:40PM +0100, Gerald Schaefer wrote: > > On Fri, 12 Feb 2016 16:57:27 +0100 > > Christian Borntraeger <borntrae...@de.ibm.com> wrote: >

Re: [BUG] random kernel crashes after THP rework on s390 (maybe also on PowerPC and ARM)

On Thu, 18 Feb 2016 01:58:08 +0200 "Kirill A. Shutemov" <kir...@shutemov.name> wrote: > On Wed, Feb 17, 2016 at 08:13:40PM +0100, Gerald Schaefer wrote: > > On Sat, 13 Feb 2016 12:58:31 +0100 (CET) > > Sebastian Ott <seb...@linux.vnet.ibm.com> wrote: > &

Re: [BUG] random kernel crashes after THP rework on s390 (maybe also on PowerPC and ARM)

On Sat, 13 Feb 2016 12:58:31 +0100 (CET) Sebastian Ott wrote: > [ 59.875935] [ cut here ] > [ 59.875937] kernel BUG at mm/huge_memory.c:2884! > [ 59.875979] illegal operation: 0001 ilc:1 [#1] PREEMPT SMP DEBUG_PAGEALLOC > [ 59.875986]

Re: [BUG] random kernel crashes after THP rework on s390 (maybe also on PowerPC and ARM)

On Mon, 15 Feb 2016 23:35:26 +0200 "Kirill A. Shutemov" <kir...@shutemov.name> wrote: > On Mon, Feb 15, 2016 at 07:37:02PM +0100, Gerald Schaefer wrote: > > On Mon, 15 Feb 2016 13:31:59 +0200 > > "Kirill A. Shutemov" <kir...@shutemov.name> wrote

Re: [BUG] random kernel crashes after THP rework on s390 (maybe also on PowerPC and ARM)

On Mon, 15 Feb 2016 13:31:59 +0200 "Kirill A. Shutemov" wrote: > On Sat, Feb 13, 2016 at 12:58:31PM +0100, Sebastian Ott wrote: > > > > On Sat, 13 Feb 2016, Kirill A. Shutemov wrote: > > > Could you check if revert of fecffad25458 helps? > > > > I reverted fecffad25458 on

Re: [BUG] random kernel crashes after THP rework on s390 (maybe also on PowerPC and ARM)

On Sat, 13 Feb 2016 01:15:10 +0200 "Kirill A. Shutemov" wrote: > > I'm trying to wrap my head around the issue and I don't think missing > serialization with gup_fast is the cause -- we just don't need it > anymore. > > Previously, __split_huge_page_splitting() required

Re: [BUG] random kernel crashes after THP rework on s390 (maybe also on PowerPC and ARM)

On Fri, 12 Feb 2016 09:34:33 +0530 "Aneesh Kumar K.V" <aneesh.ku...@linux.vnet.ibm.com> wrote: > Gerald Schaefer <gerald.schae...@de.ibm.com> writes: > > > On Thu, 11 Feb 2016 21:09:42 +0200 > > "Kirill A. Shutemov" <kir...@shutemov.name>

Re: [BUG] random kernel crashes after THP rework on s390 (maybe also on PowerPC and ARM)

On Fri, 12 Feb 2016 16:57:27 +0100 Christian Borntraeger <borntrae...@de.ibm.com> wrote: > On 02/12/2016 04:41 PM, Kirill A. Shutemov wrote: > > On Thu, Feb 11, 2016 at 08:57:02PM +0100, Gerald Schaefer wrote: > >> On Thu, 11 Feb 2016 21:09:42 +0200 > >> "Kir

Re: [BUG] random kernel crashes after THP rework on s390 (maybe also on PowerPC and ARM)

On Thu, 11 Feb 2016 21:09:42 +0200 "Kirill A. Shutemov" <kir...@shutemov.name> wrote: > On Thu, Feb 11, 2016 at 07:22:23PM +0100, Gerald Schaefer wrote: > > Hi, > > > > Sebastian Ott reported random kernel crashes beginning with v4.5-rc1 and > > he al

[BUG] random kernel crashes after THP rework on s390 (maybe also on PowerPC and ARM)

Hi, Sebastian Ott reported random kernel crashes beginning with v4.5-rc1 and he also bisected this to commit 61f5d698 "mm: re-enable THP". Further review of the THP rework patches, which cannot be bisected, revealed commit fecffad "s390, thp: remove infrastructure for handling splitting PMDs"

Re: [RFC PATCH v5 16/19] memory-hotplug: free memmap of sparse-vmemmap

On Fri, 27 Jul 2012 18:34:38 +0800 Wen Congyang we...@cn.fujitsu.com wrote: From: Yasuaki Ishimatsu isimatu.yasu...@jp.fujitsu.com All pages of virtual mapping in removed memory cannot be freed, since some pages used as PGD/PUD includes not only removed memory but also other memory. So the

Re: [RFC PATCH v5 12/19] memory-hotplug: introduce new function arch_remove_memory()

On Mon, 30 Jul 2012 18:35:37 +0800 Wen Congyang we...@cn.fujitsu.com wrote: At 07/30/2012 06:23 PM, Heiko Carstens Wrote: On Fri, Jul 27, 2012 at 06:32:15PM +0800, Wen Congyang wrote: We don't call __add_pages() directly in the function add_memory() because some other architecture related

Re: [PATCH 2/2][v2] powerpc: Make the CMM memory hotplug aware

Robert Jennings wrote: @@ -110,6 +125,9 @@ static long cmm_alloc_pages(long nr) cmm_dbg(Begin request for %ld pages\n, nr); while (nr) { + if (atomic_read(hotplug_active)) + break; + addr = __get_free_page(GFP_NOIO |

Re: [PATCH 2/2][v2] powerpc: Make the CMM memory hotplug aware

Hi, I am currently working on the s390 port for the cmm + hotplug patch, and I'm a little confused about the memory allocation policy, see below. Is it correct that the balloon cannot grow into ZONE_MOVABLE, while the pages for the balloon page list can? Robert Jennings wrote: @@ -110,6 +125,9