Re: [LTP] [PATCH 2/2] mm/lib: increase sleep time in ksm scanning

Caspar Zhang
2012-07-09T14:15:45Z

On 07/09/2012 09:10 PM, Wanlong Gao wrote:
> On 07/09/2012 08:37 PM, Caspar Zhang wrote:
>> On 07/09/2012 07:32 PM, Wanlong Gao wrote:
>>> On 07/09/2012 05:51 PM, Caspar Zhang wrote:
>>>>
>>>> for some systems under pressure, we've observed that sleeping 5
>>>> seconds is not sufficient for completing ksm scanning, to fix
>>>> this, we should give ksmd more time to scan the mergable pages
>>>> by increasing sleeping time to 10s.
>>>
>>> If 5s is not enough, isn't we waiting here already?
>>
>> Sorry, I'm not catching you... :-( the problem currently we
>> encounter is that if 5s given, all ksm values (pages_sharing,
>> pages_shared, etc) might remain the same between before and after
>> sleeping, so the wait_ksmd function could exit. But in fact the
>> kernel could be busy under pressure and it just needs more than 5s
>> to merge the same page. Using 10s as polling interval can make sure
>> if ksm values remains the same between each loop, it should
>> indicates that ksmd has done scanning correctly.
>>
>
> Oops, it's a serious problem, so can we first wait for changing and
> then wait for not changing? I'm afraid that hard coded sleep time
> can't do the right thing on some systems.

IMO the current implementation does the same thing as you suggested. We
wait for certain interval (5s for now, 10s proposed), and check if ksm
values increased, if still changing, continue next sleep interval.
Adding a "wait-for-not-changing" in fact has the same effect as
increasing the original sleep time.

theoretically, sleeping interval should be as larger as possible, but it
will cost unnecessary running time if the interval is set too big in the
this case. I'd say 10s is a "for-now-best-practice" during my several
running (both w/ and w/o pressure). Besides, I'm not sure how ksm
developers think of current ksm performance, but I think if ksmd takes
more than 10s to merge two same pages, it will be a big performance issue.

I'd suggest everyone interested in this case try 10s on your systems to
see if it works. Also if you have idea of design a flexible waiting
time, it will be perfect.

Thanks,
Caspar