Andrew Morton [mailto:a...@linux-foundation.org]
> Sent: Friday, July 12, 2019 9:20 AM
> To: chenjianhong (A)
> Cc: Michel Lespinasse ; Greg Kroah-Hartman
> ; mho...@suse.com; Vlastimil Babka
> ; Kirill A. Shutemov ; Yang
> Shi ; ja...@google.com; steve.cap...@arm.com;
> tiny.
ux-mm
; sta...@vger.kernel.org; wi...@infradead.org
Subject: Re: [PATCH] mm/mmap: fix the adjusted length error
On Sat, 18 May 2019 07:05:07 + "chenjianhong (A)"
wrote:
> I explain my test code and the problem in detail. This problem is
> found in 32-bit user process, because its
On Sat, 18 May 2019 07:05:07 + "chenjianhong (A)"
wrote:
> I explain my test code and the problem in detail. This problem is found in
> 32-bit user process, because its virtual is limited, 3G or 4G.
>
> First, I explain the bug I found. Function unmapped_area and
>
In linux version 4.4, a 32-bit process may fail to allocate 64M hugepage
memory by function shmat even though there is a 64M memory gap in
the process.
It is the adjusted length that causes the problem, introduced from
commit db4fbfb9523c935 ("mm: vm_unmapped_area() lookup function").
Accounting
return ret;
}
-Original Message-
From: Michel Lespinasse [mailto:wal...@google.com]
Sent: Saturday, May 18, 2019 8:13 AM
To: chenjianhong (A)
Cc: Greg Kroah-Hartman ; Andrew Morton
; mho...@suse.com; Vlastimil Babka ;
Kirill A. Shutemov ; Yang Shi
; ja...@google.com; steve.cap...
I worry that the proposed change turns the search from an O(log N)
worst case into a O(N) one.
To see why the current search is O(log N), it is easiest to start by
imagining a simplified search algorithm that wouldn't include the low
and high address limits. In that algorithm, backtracking
2019 2:07 PM
To: gre...@linuxfoundation.org; a...@linux-foundation.org; mho...@suse.com;
vba...@suse.cz;
kirill.shute...@linux.intel.com; yang@linux.alibaba.com; ja...@google.com;
steve.cap...@arm.com;
tiny.win...@gmail.com; wal...@google.com
Cc: chenjianhong (A) ; linux-kernel@vger.kernel.org;
linux...@kvack.
In linux version 4.4, a 32-bit process may fail to allocate 64M hugepage
memory by function shmat even though there is a 64M memory gap in
the process.
It is the adjusted length that causes the problem, introduced from
commit db4fbfb9523c935 ("mm: vm_unmapped_area() lookup function").
Accounting
8 matches
Mail list logo
