From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8C5DBC433F5 for ; Fri, 15 Apr 2022 02:42:42 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DFDC26B0071; Thu, 14 Apr 2022 22:42:41 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DACE46B0073; Thu, 14 Apr 2022 22:42:41 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C9C496B0075; Thu, 14 Apr 2022 22:42:41 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.27]) by kanga.kvack.org (Postfix) with ESMTP id BB3B16B0071 for ; Thu, 14 Apr 2022 22:42:41 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 94C9E27F33 for ; Fri, 15 Apr 2022 02:42:41 +0000 (UTC) X-FDA: 79357565322.24.EF411E7 Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by imf09.hostedemail.com (Postfix) with ESMTP id 633D2140006 for ; Fri, 15 Apr 2022 02:42:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1649990560; x=1681526560; h=message-id:subject:from:to:cc:date:in-reply-to: references:mime-version:content-transfer-encoding; bh=2+Y236hBP7nkfnh2vn34A03RyhdinQO05q3FqW+lPwk=; b=Hi629M2ropMXLNa+X99p7rM2evq8gstHPU0Xpk15Bsjg7FLaKtfyyz+z xn2IkI6fBkj5AtRlHadZS3JaEVV9GSD8IlRriK6GxJHdkNvGQ8ypK0Z4Q rQafB21V9SNCQ9A5RBQ8m718waBd9CAS8cKJ6MHPy1iyB/cWam66/Nur6 IKMHI9DqxjAl3duFcnf9yS+P7oEiiipcoOvzNSxwkXizBkqHq5OvijbIc 4p/uL49BTmIQh3w2h2LHmqM8ChAt+VSRyPcKP8kG+C7t+aLCuAxx0xPPZ 8mRR0z7YfdhphUZkShIcA/naXb6F7Pr2CxhicevreZab4fALEycTmuwiG A==; X-IronPort-AV: E=McAfee;i="6400,9594,10317"; a="263257145" X-IronPort-AV: E=Sophos;i="5.90,261,1643702400"; d="scan'208";a="263257145" Received: from orsmga006.jf.intel.com ([10.7.209.51]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Apr 2022 19:42:38 -0700 X-IronPort-AV: E=Sophos;i="5.90,261,1643702400"; d="scan'208";a="527646181" Received: from ruiqifu-mobl.ccr.corp.intel.com ([10.254.213.123]) by orsmga006-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Apr 2022 19:42:34 -0700 Message-ID: Subject: Re: [PATCH 1/3] memory tiering: hot page selection with hint page fault latency From: "ying.huang@intel.com" To: Jagdish Gediya Cc: Peter Zijlstra , Mel Gorman , Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Michal Hocko , Rik van Riel , Dave Hansen , Yang Shi , Zi Yan , Wei Xu , osalvador , Shakeel Butt , Zhong Jiang Date: Fri, 15 Apr 2022 10:42:31 +0800 In-Reply-To: References: <20220408071222.219689-1-ying.huang@intel.com> <20220408071222.219689-2-ying.huang@intel.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.38.3-1 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Rspam-User: X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: 633D2140006 X-Stat-Signature: 3rawwtfcutit1mh56obb1tnrjnpno1ar Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=Hi629M2r; spf=none (imf09.hostedemail.com: domain of ying.huang@intel.com has no SPF policy when checking 192.55.52.115) smtp.mailfrom=ying.huang@intel.com; dmarc=pass (policy=none) header.from=intel.com X-HE-Tag: 1649990560-36677 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Hi, Jagdish, On Thu, 2022-04-14 at 18:53 +0530, Jagdish Gediya wrote: > On Fri, Apr 08, 2022 at 03:12:20PM +0800, Huang Ying wrote: [snip] > > + > > +static int numa_hint_fault_latency(struct page *page) > > +{ > > + int last_time, time; > > + > > + time = jiffies_to_msecs(jiffies); > > + last_time = xchg_page_access_time(page, time); > > + > > + return (time - last_time) & PAGE_ACCESS_TIME_MASK; > > This code can possibly consider cold page as hot, > > Assume, > > LAST_CPUPID_SHIFT = 12 > PAGE_ACCESS_TIME_BUCKETS = 0 > sysctl_numa_balancing_hot_threshold = 1000 > > Assume while changing pte, > jiffies_to_msecs(jiffies) = 0xAABB0100 > > So value saved in page->flags will be lowest 12 bits of 0xAABB0100 > which is 0x100. > > Assume when numa_hint_fault_latency() gets called, > time = jiffies_to_msecs(jiffies) = 0xAACC0100 > > So, time = 0xAACC0100, and last_time = 0x100, > time - last_time = 0xAACC0100 - 0x100 = 0xAACC0000 > 0xAACC0000 & PAGE_ACCESS_TIME_MASK = 0xAACC0000 & ((1 << 12) - 1) = 0 > > so the return value of this function is 0, the code will consider it as > hot page but it is cold page because actual difference is > 0xAACC0100 - 0xAABB0100 = 110000 ms > Yes. This is possible. > There may be more such scenarios. What do you think? The algorithm just works statistically correct. That is, for really hot pages, their hint page fault latency will be short and we can promote it when they are accessed. For cold pages, it's still possible for them to be identified as hot pages. But the possibility is much lower than that of the hot pages. We can try to improve further here. But as the first step, I want to keep the algorithm as simple as possible. Then we can try improve it step by step and show benefit in each step to justify the further optimization. > > +} > > + Best Regards, Huang, Ying