Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753314AbdGKE3A (ORCPT ); Tue, 11 Jul 2017 00:29:00 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:49455 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750821AbdGKE26 (ORCPT ); Tue, 11 Jul 2017 00:28:58 -0400 Subject: Re: [RFC] mm/mremap: Remove redundant checks inside vma_expandable() To: Michal Hocko , Anshuman Khandual References: <20170710111059.30795-1-khandual@linux.vnet.ibm.com> <20170710134917.GB19645@dhcp22.suse.cz> Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, akpm@linux-foundation.org, mike.kravetz@oracle.com From: Anshuman Khandual Date: Tue, 11 Jul 2017 09:58:42 +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: <20170710134917.GB19645@dhcp22.suse.cz> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-TM-AS-MML: disable x-cbid: 17071104-0044-0000-0000-0000027D85B5 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17071104-0045-0000-0000-0000070DFBBD Message-Id: X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-07-11_01:,, 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-1703280000 definitions=main-1707110067 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1608 Lines: 50 On 07/10/2017 07:19 PM, Michal Hocko wrote: > On Mon 10-07-17 16:40:59, Anshuman Khandual wrote: >> As 'delta' is an unsigned long, 'end' (vma->vm_end + delta) cannot >> be less than 'vma->vm_end'. > > This just doesn't make any sense. This is exactly what the overflow > check is for. Maybe vm_end + delta can never overflow because of > (old_len == vma->vm_end - addr) and guarantee old_len < new_len > in mremap but I haven't checked that too deeply. Irrespective of that, just looking at the variables inside this particular function where delta is an 'unsigned long', 'end' cannot be less than vma->vm_end. Is not that true ? > >> Checking for availability of virtual >> address range at the end of the VMA for the incremental size is >> also reduntant at this point. Hence drop them both. > > OK, this seems to be the case due the above (comment says "old_len > exactly to the end of the area.."). yeah but is the check necessary ? > > But I am wondering what led you to the patch because you do not say so As can be seen in the test program, was trying to measure the speed of VMA expansion and contraction inside an address space and then figured out that dropping this check improves the speed prima facie. > here. This is hardly something that would save many cycles in a > relatively cold path. Though I have not done any detailed instruction level measurement, there is a reduction in real and system amount of time to execute the test with and without the patch. Without the patch real 0m2.100s user 0m0.162s sys 0m1.937s With this patch real 0m0.928s user 0m0.161s sys 0m0.756s