Received: by 10.223.185.111 with SMTP id b44csp1520wrg; Thu, 8 Mar 2018 23:31:40 -0800 (PST) X-Google-Smtp-Source: AG47ELtXUST3YaOMR1QfrTipwymruHdkuO4oH+3K2+zoheVbBbxxz8asmFyrXRrXco1avpq0TZDp X-Received: by 2002:a17:902:710f:: with SMTP id a15-v6mr26133657pll.87.1520580700748; Thu, 08 Mar 2018 23:31:40 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1520580700; cv=none; d=google.com; s=arc-20160816; b=WpFMrD306m1Ioeqq9wOYl0WKOBhAjN5VmopF8RW/FOvotpU1C30Cr/JeHPeevI851B HvnX45EYfEO8eJJemlJw+98/xWYHtPyE1jNEeJB+qTUURaPD6Z8Meen17LtIXep9yVKw w5m7nUWlBJ42k2fCCJKiQVSsXBfndfmIuDMrS0c+l5URXMil1XS2WJzs2tSvtExI5qfQ bHQS2M1/nlRCL0X9eo3YYsPDaJEkyZXI11WAKnjX0eGp0wNBO9lR/pcWn/sqwIuKBgcC MoNZjwVYr1Y2V4isSKyY8RCp7K5IHBjD49PWkX89qwLoogb+e6LGMlcvX8PAY3mc+J5r J1iA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:to:subject:message-id:date:from :mime-version:dkim-signature:arc-authentication-results; bh=XTeUAeoXKPwIMLQ/YWjkcA/TnyBZ5UxBMyIpezQhwVI=; b=Zqj2/yj0iZyh5I3RPKl1hzsGQ3oVxDIV7bz8ozw/pqq2fb9COSg2SSPA4xe9khR+m+ XHfOvZLTC+OTqok8iZdQQQWTLFO0kRScnXVcB/8PDg6HnaucB33YcknS2kbJr8KZd8zl eJK0liII/4L2nAdzXV1NEKctzuz15JHXaWmdQtUqAUL/OAf3rXuAVQ+pLZazA4mKdhlD fwjz8/XrmtglISjgt6UAYVchvTX2wWMHVmfAUpAm8B5bRRButKxhUBPKIHjWTX9iFQlp LdcxePIoAGVaOtmkBz2fhDK6OsTVd0yd/+vP5c8uSmtRvSu83h1yXZNFSP4hMFiyFrzT HKIg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@virginia-edu.20150623.gappssmtp.com header.s=20150623 header.b=pyhvy0Rc; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b34-v6si410317plc.439.2018.03.08.23.31.26; Thu, 08 Mar 2018 23:31:40 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@virginia-edu.20150623.gappssmtp.com header.s=20150623 header.b=pyhvy0Rc; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751419AbeCIH36 (ORCPT + 99 others); Fri, 9 Mar 2018 02:29:58 -0500 Received: from mail-qt0-f173.google.com ([209.85.216.173]:44962 "EHLO mail-qt0-f173.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751170AbeCIH34 (ORCPT ); Fri, 9 Mar 2018 02:29:56 -0500 Received: by mail-qt0-f173.google.com with SMTP id g60so9697748qtd.11 for ; Thu, 08 Mar 2018 23:29:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=virginia-edu.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=XTeUAeoXKPwIMLQ/YWjkcA/TnyBZ5UxBMyIpezQhwVI=; b=pyhvy0RcsPqwg0XaFBgKWjLR4PzUlvqqN3GzGRVbh8vjgnr7RWwlMJsqba21NozNjs fmJKZ5QuhT1wVSDKUpyLkRryGoldlpGprpIQZ/ZRaOQm0G5IcD4/NXVzjCjXWUUZxtPY jxgnZRbhmQgb+TNOe7BMNriu/YAXp/3SlnZKNSE/WATwFo2PRceFYwoE7T8+uUAVh25m yaZ4nP1rRjHYmIkHM4251Jg9DzTNWS+ZuNmW6i1YnZpGhvJsQrvrr3dIm102Gua0zet1 TaaUydUK71/6DbwjUINiReSCI3tTh+PgisfjOVx6MtHGNjXGMWyr8WFPXkSklziUsNyq 3Ylw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=XTeUAeoXKPwIMLQ/YWjkcA/TnyBZ5UxBMyIpezQhwVI=; b=obwuJ/5Pt+fQwiTRXgrJgx7TAQwZVw/ezk952DWJP6vYXh8kQdG1ufW9rXKUtEIczy B7bQWdXhbCUHuPWgb3UhqzxgqsBRCci4H20j2Bgb9S+8lDL48y3h4hR8zJcsRpgeereT 0S0rYI4So8kwQ3ky7QBlrB+eodoDrqKLpYNG8ii03jV8s8DOQpn5D/p18D5aAPAGvUI+ CvPRp1bm9xCmR1bM/zHLlXYnOq3oXWQozSunAwGn4n+eBYzo5syy5ML0wpfwV0aKB4Hy yXUtJUjIbfMMrQu+f07yPiNur8dh0/409pUJ2UdnFfl3Uv3NqyuWgyPR9sYzvVnf+GY/ ZT8g== X-Gm-Message-State: AElRT7EECPZ5ddoHDEO/Q98+eMHnLA8VsSf13yy74PNpRDc/OXTGLTOy pixj8zeyZEpUayC+rKXxwut//hqlrBEVwZblEbSnHujW X-Received: by 10.237.32.226 with SMTP id 89mr46077412qtb.150.1520580595614; Thu, 08 Mar 2018 23:29:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.24.172 with HTTP; Thu, 8 Mar 2018 23:29:55 -0800 (PST) From: Will Hawkins Date: Fri, 9 Mar 2018 02:29:55 -0500 Message-ID: Subject: x86 performance monitor counters save/restore on context switch To: Steven Rostedt , LKML Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Mr. Rostedt and others interested reading on the LKML, I hope that this is the proper venue to ask this (longwinded) question. If it is not, I apologize for the SPAM and wasting everyone's time and bits. I am emailing to ask for clarification about the "policy" of saving and restoring x86 performance monitor counters (and other PMU-related registers) on context switch in the Kernel. Having plumbed through the code for scheduling, I get the sense that code in the perf subsystem is the only code that would, if conditions are right, save/restore performance registers on a context switch. In my investigation, I started from the top where prepare_task_switch() calls perf_event_task_sched_out() and where finish_task_switch() calls perf_event_task_sched_in(). Having traced the implementation of each of those functions to (what I think is) their lowest levels, the Kernel will only save and restore performance monitor counters if: 1. The task, process of task's CPU is actively monitoring performance. That monitoring would have been initiated by a user by calling perf_event_open() (or using a high level library that eventually calls that function). 2. The performance aspects being monitored are hardware counters/events. I am sure that there are other conditions, but those are the two that stuck out to me the most. All that is a long (perhaps incorrect) preface to a very simple question: Is it only the performance counting registers that are actively in use (again, as told to the perf subsystem by a call to perf_event_open()) that are saved/restored on context switch? I ask because I have written code (mostly out of curiosity and not necessarily for production) that accesses those registers directly by writing/reading their values through the msr kernel module. If what I said above is correct, then I have to be wary of the fact that the values read from those counters reflect statistics from all the processes/threads running on the same CPU at the same time. At first blush, this was the way I expected the performance monitoring registers and counters to work, but I wanted to confirm and you seemed like the right person to ask. If I was wrong about asking for your help, I apologize and hope that I didn't waste your valuable time. Thanks for all the work that you do on the performance monitoring systems for Linux -- they are invaluable for debugging those hard-to-find bottlenecks that inevitably pop up when you really need something to "just work." Will .