Received: by 10.223.185.116 with SMTP id b49csp4181324wrg; Tue, 13 Feb 2018 14:18:25 -0800 (PST) X-Google-Smtp-Source: AH8x226Y30Ec+/SUEdRzrCX4ep6k0ZoEnATBSgwToc2qt0RIsXKS5sBVoT8agQzR7GKhc4IPqhaA X-Received: by 10.98.208.3 with SMTP id p3mr2642852pfg.8.1518560305535; Tue, 13 Feb 2018 14:18:25 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1518560305; cv=none; d=google.com; s=arc-20160816; b=OBjnoys/QC1tjqBvNnkamxE6txy9qPqp8zWNH9oft3HfwbqSYNMhvtPd38krfuUCvU mRZF/A3IoDG+JlaKq34Nm/JEUDrKKqNpMarwczhNTnWT2KGkAhy+OC2+4uU/uD5GGpkh e05EbWQJoMuOKuMIMZto4a1O+Stt106hZySjEhctyaCFrTxS7abFj/1s/RcF1SWO8oc7 DKvHDMwnc7nAIlmM1yQikQoWnvGcczxOLeOP2ics0XTdgTi6eVrObPDl+kOLapnYCyMY FCKDjG4N24KZh/R5T90ZqvbiLGolx050LmpTyFPkEo87d5Ag8DAyuL+0pS64UyDuqaPw XRkQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:message-id:references :in-reply-to:subject:cc:to:from:date:content-transfer-encoding :mime-version:dkim-signature:dkim-signature :arc-authentication-results; bh=f9woNEV1R6wC1xv0Yct1/UyXOzMVqTAdatELs/qRLCo=; b=SHxqZ7DzxUn+tb9TmScA44QgZ7YU4+EnLGjgp0lKswjlpJJFc5ioDQezVIPHTXDp1f wzf0kyQmUFW1AsvFxZwLgNoVm9/u+oTssmp5MJDVEBLCk6LCCM8T7nsd5OEMPacsuouc v3Tq6bY7N4KHW16WZZHVc/ZTruZgoq/RP3fSLKQcKm0L4ZXhXrc0VYXpGiz4LvUAJxcl ib42yUIdy1Ou+TV5GXjxrAY/JRde11DodxIxhOZl7d+c35wwQLu/XUUrUTdEiG9HCV4N ToLjHqUKk6+9SxxZO0sJOovVyvuX3H5WPoEsx6jvUJdAVdh1iw8ONFqjqq9E6l8/ug4x 9UXA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@codeaurora.org header.s=default header.b=Sipp9MRB; dkim=pass header.i=@codeaurora.org header.s=default header.b=Sipp9MRB; 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 h90si418514pfa.257.2018.02.13.14.17.51; Tue, 13 Feb 2018 14:18:25 -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=@codeaurora.org header.s=default header.b=Sipp9MRB; dkim=pass header.i=@codeaurora.org header.s=default header.b=Sipp9MRB; 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 S965949AbeBMWRJ (ORCPT + 99 others); Tue, 13 Feb 2018 17:17:09 -0500 Received: from smtp.codeaurora.org ([198.145.29.96]:36632 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965900AbeBMWRI (ORCPT ); Tue, 13 Feb 2018 17:17:08 -0500 Received: by smtp.codeaurora.org (Postfix, from userid 1000) id DB2A960F6E; Tue, 13 Feb 2018 22:17:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1518560227; bh=zrG1deyL0VVOGgxY54bCqXcQwbyJtXPn9x+QdAV72A0=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=Sipp9MRBqRQcjhMKpEgn2oJaEOBciWrU5GffDqWoDJ/TRuVxs0o0o9Q+tUsTDKYN6 p8gfx4jWfQozSywylcgYYfNYXMeqdnU9fWrJJMmunfMaZ0Al18qwcw4QrjSep4JaYY Q2IRKZzQgLDH3GS0XX0/nJm/8Q/EXmaE81+9CBuQ= X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on pdx-caf-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.8 required=2.0 tests=ALL_TRUSTED,BAYES_00, DKIM_SIGNED,T_DKIM_INVALID autolearn=no autolearn_force=no version=3.4.0 Received: from mail.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.codeaurora.org (Postfix) with ESMTP id 5EA0760386; Tue, 13 Feb 2018 22:17:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1518560227; bh=zrG1deyL0VVOGgxY54bCqXcQwbyJtXPn9x+QdAV72A0=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=Sipp9MRBqRQcjhMKpEgn2oJaEOBciWrU5GffDqWoDJ/TRuVxs0o0o9Q+tUsTDKYN6 p8gfx4jWfQozSywylcgYYfNYXMeqdnU9fWrJJMmunfMaZ0Al18qwcw4QrjSep4JaYY Q2IRKZzQgLDH3GS0XX0/nJm/8Q/EXmaE81+9CBuQ= MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 13 Feb 2018 14:17:07 -0800 From: Sodagudi Prasad To: Peter Zijlstra Cc: Raghavendra Rao Ananta , mingo@redhat.com, acme@kernel.org, alexander.shishkin@linux.intel.com, jolsa@redhat.com, namhyung@kernel.org, linux-kernel@vger.kernel.org, tsoni@codeaurora.org Subject: Re: [PATCH] perf: Add support for creating offline events In-Reply-To: <20180213182351.GQ25201@hirez.programming.kicks-ass.net> References: <1518217620-28458-1-git-send-email-rananta@codeaurora.org> <20180213182351.GQ25201@hirez.programming.kicks-ass.net> Message-ID: <7d3d97fafa654c30b4ca776180760cb3@codeaurora.org> X-Sender: psodagud@codeaurora.org User-Agent: Roundcube Webmail/1.2.5 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2018-02-13 10:23, Peter Zijlstra wrote: > On Fri, Feb 09, 2018 at 03:07:00PM -0800, Raghavendra Rao Ananta wrote: >> Perf framework doesn't allow creation of hardware events if >> the requested CPU is offline. However, creation of an event >> is achievable if the event is attached to the PMU as soon >> as the CPU is online again. >> >> So, introducing a feature that could allow to create events >> even when the CPU is offline and return a success to the caller. >> If, during the time of event creation, the CPU is found offline, >> the event is moved to a new state (PERF_EVENT_STATE_DORMANT). As >> and when the CPU is know to be woken up (through hotplug notifiers), >> all the dormant events would be attached to the PMU (by >> perf_install_in_context()). If during the life time of the event, >> the CPU hasn't come online, the dormant event would just be freed. > > This is horrible.. and you seem to have forgotten to explain why you > care about offline CPUs. Hi Peter, Up to 4.9 kernel, drivers can register cpu hotplug notfiters and drivers are able to create perf events dynamically based cpu notifies callback events. As cpu hot plug is converted to state machine approach from hot plug notifiers, every driver need to define a cpuhp state and registers with cpu hotplug state machine for creating perf events dynamically. Qualcomm have use cases to monitor the cpu cycles and other hw events continuously on all cpus from kernel and profiling tools. So we are thinking that there could be other soc vendors, who are interested in perf events preserving across cpu hot plug and perf events creation on hot plugged cores. -Thanks, Prasad -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, Linux Foundation Collaborative Project