Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752601AbdLNNaq (ORCPT ); Thu, 14 Dec 2017 08:30:46 -0500 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:49608 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752512AbdLNNao (ORCPT ); Thu, 14 Dec 2017 08:30:44 -0500 Subject: Re: [PATCH V2] mm/mprotect: Add a cond_resched() inside change_pmd_range() To: Michal Hocko , Anshuman Khandual References: <20171214111426.25912-1-khandual@linux.vnet.ibm.com> <20171214112928.GH16951@dhcp22.suse.cz> <28e54a80-73d9-76aa-31d5-f71375f14b96@linux.vnet.ibm.com> <20171214130435.GL16951@dhcp22.suse.cz> <20171214132753.GN16951@dhcp22.suse.cz> Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, akpm@linux-foundation.org From: Anshuman Khandual Date: Thu, 14 Dec 2017 19:00:36 +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: <20171214132753.GN16951@dhcp22.suse.cz> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 x-cbid: 17121413-0016-0000-0000-0000050D19B6 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17121413-0017-0000-0000-0000284933D7 Message-Id: <988a79ce-2803-85e7-d810-b4b2d4ba6b26@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-12-14_07:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1712140185 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1920 Lines: 43 On 12/14/2017 06:57 PM, Michal Hocko wrote: > On Thu 14-12-17 18:50:41, Anshuman Khandual wrote: >> On 12/14/2017 06:34 PM, Michal Hocko wrote: >>> On Thu 14-12-17 18:25:54, Anshuman Khandual wrote: >>>> On 12/14/2017 04:59 PM, Michal Hocko wrote: >>>>> On Thu 14-12-17 16:44:26, Anshuman Khandual wrote: >>>>>> diff --git a/mm/mprotect.c b/mm/mprotect.c >>>>>> index ec39f73..43c29fa 100644 >>>>>> --- a/mm/mprotect.c >>>>>> +++ b/mm/mprotect.c >>>>>> @@ -196,6 +196,7 @@ static inline unsigned long change_pmd_range(struct vm_area_struct *vma, >>>>>> this_pages = change_pte_range(vma, pmd, addr, next, newprot, >>>>>> dirty_accountable, prot_numa); >>>>>> pages += this_pages; >>>>>> + cond_resched(); >>>>>> } while (pmd++, addr = next, addr != end); >>>>>> >>>>>> if (mni_start) >>>>> this is not exactly what I meant. See how change_huge_pmd does continue. >>>>> That's why I mentioned zap_pmd_range which does goto next... >>>> I might be still missing something but is this what you meant ? >>> yes, except >>> >>>> Here we will give cond_resched() cover to the THP backed pages >>>> as well. >>> but there is still >>> if (!is_swap_pmd(*pmd) && !pmd_trans_huge(*pmd) && !pmd_devmap(*pmd) >>> && pmd_none_or_clear_bad(pmd)) >>> continue; >>> >>> so we won't have scheduling point on pmd holes. Maybe this doesn't >>> matter, I haven't checked but why should we handle those differently? >> >> May be because it is not spending much time for those entries which >> can really trigger stalls, hence they dont need scheduling points. >> In case of zap_pmd_range(), it was spending time either in >> __split_huge_pmd() or zap_huge_pmd() hence deserved a scheduling point. > > As I've said, I haven't thought much about that but the discrepancy just > hit my eyes. So if there is not a really good reason I would rather use > goto next consistently. Sure, will respin with the changes.