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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 119C6C433F5 for ; Tue, 3 May 2022 23:54:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S244408AbiECX5w (ORCPT ); Tue, 3 May 2022 19:57:52 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39274 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230087AbiECX5u (ORCPT ); Tue, 3 May 2022 19:57:50 -0400 Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2459E2D1C4 for ; Tue, 3 May 2022 16:54:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1651622056; x=1683158056; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=K8SvhxQm1P62rJiCvMA6jYehYxpt5BXqhVT4BJHzqCc=; b=cfuj9TgIlHxV3jgOtttBOUu7YbI/vb1yqUlZ9eW2kP2eWnWnXC6ACGm/ 1sPyxRtp6GfVq/0N+AtWMKO00KAkdU40X6/z5Vwq2a8DVV7dP0iQZxlvM +AMn2xOYoVmxSiiy4XSs3GqWxnOnhYXveBqT67yWIeDuRTvJXiYuOEg39 bq26vZxqwadK3KT7IONGV0pZAUqXoe3DXRVyqA28qNUXx9KEHbJ3CbhBc EmN1x+REKSb4gf5YO1UV+qC357iBBZc0P+VV5HzBdoAVw1SMNRctXSMrv nL4u/aZqONF/cP59RRIHHQnIw7mz8wkPg21PiUudsyYwSF20jcTaa1pQ2 w==; X-IronPort-AV: E=McAfee;i="6400,9594,10336"; a="248163425" X-IronPort-AV: E=Sophos;i="5.91,196,1647327600"; d="scan'208";a="248163425" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 May 2022 16:54:15 -0700 X-IronPort-AV: E=Sophos;i="5.91,196,1647327600"; d="scan'208";a="664202274" Received: from dbandax-mobl2.amr.corp.intel.com (HELO [10.209.188.251]) ([10.209.188.251]) by fmsmga002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 May 2022 16:54:14 -0700 Message-ID: <9fb22767-54de-d316-7e6b-5aac375c9c49@intel.com> Date: Tue, 3 May 2022 16:54:34 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: RFC: Memory Tiering Kernel Interfaces Content-Language: en-US To: Alistair Popple Cc: Davidlohr Bueso , Wei Xu , Andrew Morton , Dave Hansen , Huang Ying , Dan Williams , Yang Shi , Linux MM , Greg Thelen , "Aneesh Kumar K.V" , Jagdish Gediya , Linux Kernel Mailing List , Michal Hocko , Baolin Wang , Brice Goglin , Feng Tang , Jonathan.Cameron@huawei.com References: <20220501175813.tvytoosygtqlh3nn@offworld> <87o80eh65f.fsf@nvdebian.thelocal> <87mtfygoxs.fsf@nvdebian.thelocal> From: Dave Hansen In-Reply-To: <87mtfygoxs.fsf@nvdebian.thelocal> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 5/3/22 15:35, Alistair Popple wrote: > Not entirely true. The GPUs on POWER9 have performance counters capable of > collecting this kind of information for memory accessed from the GPU. I will > admit though that sadly most people probably don't have a P9 sitting under their > desk :) Well, x86 CPUs have performance monitoring hardware that can theoretically collect physical access information too. But, this performance monitoring hardware wasn't designed for this specific use case in mind. So, in practice, these events (PEBS) weren't very useful for driving memory tiering. Are you saying that the GPUs on POWER9 have performance counters that can drive memory tiering in practice? I'd be curious if there's working code to show how they get used. Maybe the hardware is better than the x86 PMU or the software consuming it is more clever than what we did. But, I'd love to see it either way.