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 X-Spam-Level: X-Spam-Status: No, score=-5.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7EF30C35254 for ; Mon, 17 Feb 2020 11:58:18 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 5E04020725 for ; Mon, 17 Feb 2020 11:58:18 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729074AbgBQL6S (ORCPT ); Mon, 17 Feb 2020 06:58:18 -0500 Received: from mx2.suse.de ([195.135.220.15]:38340 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728773AbgBQL6R (ORCPT ); Mon, 17 Feb 2020 06:58:17 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 7594CAAC2; Mon, 17 Feb 2020 11:58:15 +0000 (UTC) Date: Mon, 17 Feb 2020 11:58:10 +0000 From: Mel Gorman To: Peter Zijlstra Cc: ?????? , Ingo Molnar , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Ben Segall , Luis Chamberlain , Kees Cook , Iurii Zaikin , Michal Koutn? , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, "Paul E. McKenney" , Randy Dunlap , Jonathan Corbet Subject: Re: [PATCH RESEND v8 1/2] sched/numa: introduce per-cgroup NUMA locality info Message-ID: <20200217115810.GA3420@suse.de> References: <20200214151048.GL14914@hirez.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20200214151048.GL14914@hirez.programming.kicks-ass.net> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-doc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-doc@vger.kernel.org On Fri, Feb 14, 2020 at 04:10:48PM +0100, Peter Zijlstra wrote: > On Fri, Feb 07, 2020 at 11:35:30AM +0800, ?????? wrote: > > By monitoring the increments, we will be able to locate the per-cgroup > > workload which NUMA Balancing can't helpwith (usually caused by wrong > > CPU and memory node bindings), then we got chance to fix that in time. > > > > Cc: Mel Gorman > > Cc: Peter Zijlstra > > Cc: Michal Koutný > > Signed-off-by: Michael Wang > > So here: > > https://lkml.kernel.org/r/20191127101932.GN28938@suse.de > > Mel argues that the information exposed is fairly implementation > specific and hard to use without understanding how NUMA balancing works. > > By exposing it to userspace, we tie ourselves to these particulars. We > can no longer change these NUMA balancing details if we wanted to, due > to UAPI concerns. > > Mel, I suspect you still feel that way, right? > Yes, I still think it would be a struggle to interpret the data meaningfully without very specific knowledge of the implementation. If the scan rate was constant, it would be easier but that would make NUMA balancing worse overall. Similarly, the stat might get very difficult to interpret when NUMA balancing is failing because of a load imbalance, pages are shared and being interleaved or NUMA groups span multiple active nodes. For example, the series that reconciles NUMA and CPU balancers may look worse in these stats even though the overall performance may be better. > In the document (patch 2/2) you write: > > > +However, there are no hardware counters for per-task local/remote accessing > > +info, we don't know how many remote page accesses have occurred for a > > +particular task. > > We can of course 'fix' that by adding a tracepoint. > > Mel, would you feel better by having a tracepoint in task_numa_fault() ? > A bit, although interpreting the data would still be difficult and the tracepoint would have to include information about the cgroup. While I've never tried, this seems like the type of thing that would be suited to a BPF script that probes task_numa_fault and extract the information it needs. -- Mel Gorman SUSE Labs