From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-186.mta0.migadu.com (out-186.mta0.migadu.com [91.218.175.186]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8F0A02BD5AF for ; Sun, 8 Feb 2026 09:32:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.186 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770543152; cv=none; b=AXhrS7BKHcVukkf+gPlYupL0jh07W0yQUbWAYkPh3yddU2fVDplg4Mi+uKWovEEH47R0VweHe0Tzpgo/r1XTuwxCwNYpHIAgfZSmQgA5elTSBCTAW8YbEImli36hnA6xzxv4fa9QYP6TRXPSuOp1TesYqk/4VbprmJpImHEKeks= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770543152; c=relaxed/simple; bh=tSMD7FOnoZns+sjNOrgUVfsWtcQnjnY3fNs5Abd4Jxk=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=CqFqVhol8/6Sk7gPgf+T/XOcgFRo3iVFfNd6zAoGEnQBPpjkLCQjCjSUzR52O2IeAnWefkHwAzICFZhkKpBTURLdjVgibVACAWhHVjPsT+8hYKK8Zakv7z3S+MRluKTfgumfP9M0yn5TDGRZhbEw3JmPFU7v/oOAbgkTlKcSbvg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=QzmQj6Kn; arc=none smtp.client-ip=91.218.175.186 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="QzmQj6Kn" Message-ID: <9942f80a-5a99-4e43-8053-8e6707c39252@linux.dev> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1770543150; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=TmASjvYRr/8iOkWpBFHMDIcEFajTddtRmV+cC/u8J+0=; b=QzmQj6KnX3F1OfGkKBEXhavzhDn0k9imbTb9pT7ynRewH4PpjHDeHWtodwzJgMvPHxCnXo 2IWxeXF1lTnInzvtBSwtl5H2v5K7Fduu/DK7RbUkYgFR2xbpaRHCcm3Tqsk38aK0CEu+qL 5V919FzBg0utsAxp+M424qUGfw+4zAU= Date: Sun, 8 Feb 2026 17:32:23 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Subject: Re: [PATCH mm-new v6 2/5] mm: khugepaged: refine scan progress number Content-Language: en-US To: Dev Jain , Vernon Yang , "David Hildenbrand (Arm)" Cc: akpm@linux-foundation.org, lorenzo.stoakes@oracle.com, ziy@nvidia.com, baohua@kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Vernon Yang References: <20260201122554.1470071-1-vernon2gm@gmail.com> <20260201122554.1470071-3-vernon2gm@gmail.com> <85e8ded9-a9eb-4663-9c96-93af60006fb6@kernel.org> <9508744b-e5d5-49ef-825f-eef683892541@arm.com> <1a6d8295-e27b-4440-a367-af0432a7af4f@kernel.org> <6zltgzs24wpypzu36ldwgtzilhv2z3ofuu45azp5u45huiwqvj@6jhhp5r24po6> <78b9bb1c-21aa-435f-a697-ebbfbe604a5a@arm.com> X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Lance Yang In-Reply-To: <78b9bb1c-21aa-435f-a697-ebbfbe604a5a@arm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Migadu-Flow: FLOW_OUT On 2026/2/8 17:05, Dev Jain wrote: > > On 06/02/26 4:42 pm, Vernon Yang wrote: >> On Fri, Feb 06, 2026 at 10:02:48AM +0100, David Hildenbrand (Arm) wrote: >>> On 2/5/26 15:25, Dev Jain wrote: >>>> On 05/02/26 5:41 pm, David Hildenbrand (arm) wrote: >>>>> On 2/5/26 07:08, Vernon Yang wrote: >>>>>> On Thu, Feb 5, 2026 at 5:35 AM David Hildenbrand (arm) >>>>>> wrote: >>>>>> >>>>>> I guess, your meaning is "min(_pte - pte + 1, HPAGE_PMD_NR)", not max(). >>>>> Yes! >>>>> >>>>>> >>>>>> I'm also worried that the compiler can't optimize this since the body of >>>>>> the loop is complex, as with Dev's opinion [1]. >>>>> Why do we even have to optimize this? :) >>>>> >>>>> Premature ... ? :) >>>> >>>> I mean .... we don't, but the alternate is a one liner using max(). >>> I'm fine with the max(), but it still seems like adding complexity to >>> optimize something that is nowhere prove to really be a problem. >> Hi David, Dev, >> >> I use "*cur_progress += 1" at the beginning of the loop, the compiler >> optimize that. Assembly as follows: >> >> 60c1: 4d 29 ca sub %r9,%r10 // r10 is _pte, r9 is pte, r10 = _pte - pte >> 60c4: b8 00 02 00 00 mov $0x200,%eax // eax = HPAGE_PMD_NR >> 60c9: 44 89 5c 24 10 mov %r11d,0x10(%rsp) // >> 60ce: 49 c1 fa 03 sar $0x3,%r10 // >> 60d2: 49 83 c2 01 add $0x1,%r10 // r10 += 1 >> 60d6: 49 39 c2 cmp %rax,%r10 // r10 = min(r10, eax) >> 60d9: 4c 0f 4f d0 cmovg %rax,%r10 // >> 60dd: 44 89 55 00 mov %r10d,0x0(%rbp) // *cur_progress = r10 >> >> To make the code simpler, Let us use "*cur_progress += 1". > > Wow! Wasn't expecting that. What's your gcc version? I checked with > gcc 11.4.0 (looks pretty old) with both x86 and arm64, and it couldn't > optimize. FWIW, 11.4.0 is newer that the minimum GCC version (8.1) required by kernel. See Documentation/process/changes.rst The optimization might just be version-dependent :)