On Sat, 18 May 2019 07:05:07 +0000 "chenjianhong (A)" chenjianhong2@huawei.com 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 unmapped_area_topdowns adjust search length to account for worst case alignment overhead, the code is ' length = info->length + info->align_mask; '. The variable info->length is the length we allocate and the variable info->align_mask accounts for the alignment, because the gap_start or gap_end value also should be an alignment address, but we can't know the alignment offset. So in the current algorithm, it uses the max alignment offset, this value maybe zero or other(0x1ff000 for shmat function). Is it reasonable way? The required value is longer than what I allocate. What's more, why for the first time I can allocate the memory successfully Via shmat, but after releasing the memory via shmdt and I want to attach again, it fails. This is not acceptable for many people.
Second, I explain my test code. The code I have sent an email. The following is the step. I don't think it's something unusual or unreasonable, because the virtual memory space is enough, but the process can allocate from it. And we can't pass explicit addresses to function mmap or shmat, the address is getting from the left vma gap. 1, we allocat large virtual memory; 2, we allocate hugepage memory via shmat, and release one of the hugepage memory block; 3, we allocate hugepage memory by shmat again, this will fail.
How significant is this problem in real-world use cases? How much trouble is it causing?
Third, I want to introduce my change in the current algorithm. I don't change the current algorithm. Also, I think there maybe a better way to fix this error. Nowadays, I can just adjust the gap_start value.
Have you looked further into this? Michel is concerned about the performance cost of the current solution.