From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1754971AbcL0Vjo (ORCPT <rfc822;w@1wt.eu>);
        Tue, 27 Dec 2016 16:39:44 -0500
Received: from mail-ua0-f172.google.com ([209.85.217.172]:36356 "EHLO
        mail-ua0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1752636AbcL0Vjn (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Tue, 27 Dec 2016 16:39:43 -0500
MIME-Version: 1.0
In-Reply-To: <alpine.DEB.2.10.1612271206460.5815@vshiva-Udesk>
References: <1481929988-31569-1-git-send-email-vikas.shivappa@linux.intel.com>
 <1481929988-31569-2-git-send-email-vikas.shivappa@linux.intel.com>
 <20161223123228.GQ3107@twins.programming.kicks-ass.net> <alpine.DEB.2.10.1612231126590.32409@vshiva-Udesk>
 <20161223203318.GU3107@twins.programming.kicks-ass.net> <alpine.DEB.2.10.1612241747170.32409@vshiva-Udesk>
 <87vau5gn1w.fsf@firstfloor.org> <alpine.DEB.2.10.1612271206460.5815@vshiva-Udesk>
From: David Carrillo-Cisneros <davidcc@google.com>
Date: Tue, 27 Dec 2016 13:38:38 -0800
Message-ID: <CALcN6mi4VoBBPFba1hnS7V0W2QLuE8-RirPL0wC3kjrwV-8Vgg@mail.gmail.com>
Subject: Re: [PATCH 01/14] x86/cqm: Intel Resource Monitoring Documentation
To: Shivappa Vikas <vikas.shivappa@intel.com>
Cc: Andi Kleen <andi@firstfloor.org>,
        Peter Zijlstra <peterz@infradead.org>,
        Vikas Shivappa <vikas.shivappa@linux.intel.com>,
        linux-kernel <linux-kernel@vger.kernel.org>, x86 <x86@kernel.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        "Shankar, Ravi V" <ravi.v.shankar@intel.com>,
        "Luck, Tony" <tony.luck@intel.com>, Fenghua Yu <fenghua.yu@intel.com>,
        Stephane Eranian <eranian@google.com>, hpa@zytor.com
Content-Type: text/plain; charset=UTF-8
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

 The perf overhead i was thinking atleast was during the context switch which
> is the more constant overhead (the event creation is just one time).
>
> -I was trying to see an alternative where
> 1.user specifies the continuous monitor with perf-attr in open
> 2.driver allocates the task/cgroup RMID and stores the RMID in cgroup or
> task_struct
> 3.turns off the event. (hence no perf ctx switch overhead? (all the perf
> hook calls for start/stop/add we dont need any of those -
> i was still finding out if this route works basically if i turn off the
> event there is minimal overhead for the event and not start/stop/add calls
> for the event.)
> 4.but during switch_to driver writes the RMID MSR, so we still monitor.
> 5.read -> calls the driver -> driver just returns the count by reading the
> RMID.

This option breaks user expectations about an event. If an event is
closed, it's gone.
It shouldn't leave some state behind.

Do you have thoughts about adding the one cgroup file to
the intel_cmt pmu directory?

Thanks,
David