On 05/25/2017 03:16 AM, Xishi Qiu wrote:
> On 2017/5/24 21:16, Vlastimil Babka wrote:
I agree about yisheng's fix (but v2 didn't address my comments). I don't
think we should add the hunk below, as that deviates from the rest of
the design.
>>>
>>> Hi Vlastimil,
>>>
>>> The rest
On 2017/5/24 21:16, Vlastimil Babka wrote:
> On 05/24/2017 02:10 PM, Xishi Qiu wrote:
>> On 2017/5/24 19:52, Vlastimil Babka wrote:
>>
>>> On 05/24/2017 01:38 PM, Xishi Qiu wrote:
>
> Race condition with what? Who else would isolate our pages?
>
Hi Vlastimil,
I find
Hi Vlastimil,
Thanks for comment.
On 2017/5/24 19:52, Vlastimil Babka wrote:
> On 05/24/2017 01:38 PM, Xishi Qiu wrote:
>>>
>>> Race condition with what? Who else would isolate our pages?
>>>
>>
>> Hi Vlastimil,
>>
>> I find the root cause, if the page was not cached on the current cpu,
>> lru_add
On 05/24/2017 02:10 PM, Xishi Qiu wrote:
> On 2017/5/24 19:52, Vlastimil Babka wrote:
>
>> On 05/24/2017 01:38 PM, Xishi Qiu wrote:
Race condition with what? Who else would isolate our pages?
>>>
>>> Hi Vlastimil,
>>>
>>> I find the root cause, if the page was not cached on the curr
On 2017/5/24 19:52, Vlastimil Babka wrote:
> On 05/24/2017 01:38 PM, Xishi Qiu wrote:
>>>
>>> Race condition with what? Who else would isolate our pages?
>>>
>>
>> Hi Vlastimil,
>>
>> I find the root cause, if the page was not cached on the current cpu,
>> lru_add_drain() will not push it to LRU.
On 05/24/2017 01:38 PM, Xishi Qiu wrote:
>>
>> Race condition with what? Who else would isolate our pages?
>>
>
> Hi Vlastimil,
>
> I find the root cause, if the page was not cached on the current cpu,
> lru_add_drain() will not push it to LRU. So we should handle fail
> case in mlock_vma_page().
On 2017/5/24 18:32, Vlastimil Babka wrote:
> On 05/24/2017 10:32 AM, Yisheng Xie wrote:
>> Hi Kefeng，
>> Could you please try this patch.
>>
>> Thanks
>> Yisheng Xie
>> -
>> From a70ae975756e8e97a28d49117ab25684da631689 Mon Sep 17 00:00:00 2001
>> From: Yisheng Xie
>> Date: Wed, 24 Ma
On 2017/5/24 18:32, Vlastimil Babka wrote:
> On 05/24/2017 10:32 AM, Yisheng Xie wrote:
>> Hi Kefeng，
>> Could you please try this patch.
>>
>> Thanks
>> Yisheng Xie
>> -
>> From a70ae975756e8e97a28d49117ab25684da631689 Mon Sep 17 00:00:00 2001
>> From: Yisheng Xie
>> Date: Wed, 24 Ma
On 05/24/2017 12:32 PM, Vlastimil Babka wrote:
>
> Weird, I can reproduce the issue on my desktop's 4.11 distro kernel, but
> not in qemu and small kernel build, for some reason. So I couldn't test
Ah, Tetsuo's more aggressive testcase worked and I can confirm the fix.
However this would be sligh
On 05/24/2017 10:32 AM, Yisheng Xie wrote:
> Hi Kefeng，
> Could you please try this patch.
>
> Thanks
> Yisheng Xie
> -
> From a70ae975756e8e97a28d49117ab25684da631689 Mon Sep 17 00:00:00 2001
> From: Yisheng Xie
> Date: Wed, 24 May 2017 16:01:24 +0800
> Subject: [PATCH] mlock: fix ml
On 2017/5/24 16:32, Yisheng Xie wrote:
> Hi Kefeng，
> Could you please try this patch.
It works for me, thanks.
Kefeng.
>
> Thanks
> Yisheng Xie
> -
>>From a70ae975756e8e97a28d49117ab25684da631689 Mon Sep 17 00:00:00 2001
> From: Yisheng Xie
> Date: Wed, 24 May 2017 16:01:24 +080
Hi Kefeng，
Could you please try this patch.
Thanks
Yisheng Xie
-
>From a70ae975756e8e97a28d49117ab25684da631689 Mon Sep 17 00:00:00 2001
From: Yisheng Xie
Date: Wed, 24 May 2017 16:01:24 +0800
Subject: [PATCH] mlock: fix mlock count can not decrease in race condition
Kefeng reported
Kefeng Wang wrote:
> Hi All,
>
> Mlocked in meminfo will be increasing with an small testcase, and never be
> released in mainline,
> here is a testcase[1] to reproduce the issue, but the centos7.2/7.3 will not
> increase.
>
> Is it normal?
I confirmed your problem also occurs in Linux 4.11 us
Hi All,
Mlocked in meminfo will be increasing with an small testcase, and never be
released in mainline,
here is a testcase[1] to reproduce the issue, but the centos7.2/7.3 will not
increase.
Is it normal?
Thanks,
Kefeng
[1] testcase
linux:~ # cat test_mlockall.sh
grep Mlocked /proc/meminf
14 matches
Mail list logo
