On Sun, 22 Sep 2024 03:41:57 +0200
Dan Williams wrote:
> [ add s390 folks to comment on CONFIG_FS_DAX_LIMITED ]
[...]
> > @@ -2516,6 +2545,44 @@ static vm_fault_t __vm_insert_mixed(struct
> > vm_area_struct *vma,
> > return VM_FAULT_NOPAGE;
> > }
> >
> > +vm_fault_t dax_insert_pfn(struc
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 CONFIG_TRANSPARENT_HU
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
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
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 in
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
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 complexity,
>
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
alf.
Not adding 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 approac
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:
> > &g
k & 0x03U)
> - list_add_tail(&page->lru, &mm->context.pgtable_list);
> - else
> - list_del(&page->lru);
> + if (mask & 0x03U) {
> + listed = (struct list_head *)table;
> + list_add_tail(listed, &mm->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 *)&listed->next, __pte(_PAGE_INVALID));
> + set_pte((pte_t *)&listed->prev, __pte(_PAGE_INVALID));
> + }
> spin_unlock_bh(&mm->context.lock);
> table = (unsigned long *) ((unsigned long) table | (0x01U << bit));
> tlb_remove_table(tlb, table);
Reviewed-by: Gerald Schaefer
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;
> > > +
> > > + pag
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 the
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
> > -
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
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:
>
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
> >
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 unmapping
5|5|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
34455|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
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:
> >>>
&
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 in
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 mi
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 t
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 inter
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 thi
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 +0200, Alexander Gord
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 t
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 folded
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
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 that for
> v3,
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
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 Kumar
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
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 u
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
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
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
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
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(), w
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
change for other architectures
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 | 4
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
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
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
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 w.r.t
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 respectivel
---
> 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
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 pla
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 huge_ptep_get()
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
> sugg
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
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 with
t during 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
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 hel
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) || is_defined(__ARCH_HAS_5LE
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 p
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
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);
> >> +
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
> pag
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 hugepage, so that special macro can
> be d
f-by: Christoph Hellwig
Acked-by: Gerald Schaefer
On Tue, 23 Feb 2016 22:33:45 +0300
"Kirill A. Shutemov" 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 one out.
>
> Oh. I fo
On Tue, 23 Feb 2016 13:32:21 +0300
"Kirill A. Shutemov" 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 wrote:
> >
> > > > I'm also confused by p
On Thu, 18 Feb 2016 01:58:08 +0200
"Kirill A. Shutemov" 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 wrote:
> >
> > > [ 59.875935] [ cut here ]
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] Modules linked in: bridge stp
On Mon, 15 Feb 2016 23:35:26 +0200
"Kirill A. Shutemov" 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" wrote:
> >
> > > On Sat, Feb 13, 2016 at 12:58:31
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 top of 721675fcf277cf
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 serialization against
>
On Fri, 12 Feb 2016 16:57:27 +0100
Christian Borntraeger 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
> >> "Kirill A. Shutemov" wrote:
On Fri, 12 Feb 2016 09:34:33 +0530
"Aneesh Kumar K.V" wrote:
> Gerald Schaefer writes:
>
> > On Thu, 11 Feb 2016 21:09:42 +0200
> > "Kirill A. Shutemov" wrote:
> >
> >> On Thu, Feb 11, 2016 at 07:22:23PM +0100, Gerald Schaefer wrote:
&g
On Thu, 11 Feb 2016 21:09:42 +0200
"Kirill A. Shutemov" 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 also bisected this to commit
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"
(and
On Mon, 30 Jul 2012 18:35:37 +0800
Wen Congyang 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 things need
On Fri, 27 Jul 2012 18:34:38 +0800
Wen Congyang wrote:
> From: Yasuaki Ishimatsu
>
> 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 patch checks whether page can be freed or not.
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 | __GFP_NO
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
77 matches
Mail list logo
