From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751681AbdJSGYb (ORCPT ); Thu, 19 Oct 2017 02:24:31 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:44062 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750964AbdJSGY0 (ORCPT ); Thu, 19 Oct 2017 02:24:26 -0400 Subject: Re: [PATCH] mm: mlock: remove lru_add_drain_all() To: Shakeel Butt , Andrew Morton , "Kirill A. Shutemov" , Vlastimil Babka , Michal Hocko , Joonsoo Kim , Minchan Kim , Yisheng Xie , Ingo Molnar , Greg Thelen , Hugh Dickins References: <20171018231730.42754-1-shakeelb@google.com> Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org From: Anshuman Khandual Date: Thu, 19 Oct 2017 11:54:07 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <20171018231730.42754-1-shakeelb@google.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-TM-AS-MML: disable x-cbid: 17101906-0020-0000-0000-000003C23E40 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17101906-0021-0000-0000-00004256CEA2 Message-Id: X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-10-19_03:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710190092 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 10/19/2017 04:47 AM, Shakeel Butt wrote: > Recently we have observed high latency in mlock() in our generic > library and noticed that users have started using tmpfs files even > without swap and the latency was due to expensive remote LRU cache > draining. With and without this I patch I dont see much difference in number of instructions executed in the kernel for mlock() system call on POWER8 platform just after reboot (all the pagevecs might not been filled by then though). There is an improvement but its very less. Could you share your latency numbers and how this patch is making them better. > > Is lru_add_drain_all() required by mlock()? The answer is no and the > reason it is still in mlock() is to rapidly move mlocked pages to > unevictable LRU. Without lru_add_drain_all() the mlocked pages which > were on pagevec at mlock() time will be moved to evictable LRUs but > will eventually be moved back to unevictable LRU by reclaim. So, we Wont this affect the performance during reclaim ? > can safely remove lru_add_drain_all() from mlock(). Also there is no > need for local lru_add_drain() as it will be called deep inside > __mm_populate() (in follow_page_pte()). The following commit which originally added lru_add_drain_all() during mlock() and mlockall() has similar explanation. 8891d6da ("mm: remove lru_add_drain_all() from the munlock path") "In addition, this patch add lru_add_drain_all() to sys_mlock() and sys_mlockall(). it isn't must. but it reduce the failure of moving to unevictable list. its failure can rescue in vmscan later. but reducing is better." Which sounds like either we have to handle the active to inactive LRU movement during reclaim or it can be done here to speed up reclaim later on.