Received: by 10.223.185.116 with SMTP id b49csp2450842wrg; Mon, 12 Feb 2018 09:43:40 -0800 (PST) X-Google-Smtp-Source: AH8x227p0lume44jovK9ymZxUkkQBJSumrF5l0L34ioR73xkmS+ISR4MSVfBuf2DeIKz89sr0B61 X-Received: by 2002:a17:902:bc02:: with SMTP id n2-v6mr11358671pls.52.1518457420487; Mon, 12 Feb 2018 09:43:40 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1518457420; cv=none; d=google.com; s=arc-20160816; b=Ec5utTWb9xpC6aVcT5d6FV2mjWADTCyiAMhU4RdhUq6NhtLg57m0sRQZaJucnyqR03 wl/Jt+FyPekjKoS8wpsRhky4uEn4Gu5WpKM7XlaWyg6ZmXfUuaaLQ1YRp7nsO8dP+BS4 2KKtZpSNoF+wtf4cpFLNYFWZU4khgrzLL8nYsWcxPaGrRFgc5VCSbhtWV99MjhyegxK5 Skjdb4+8j7V6k3webv8jVGiK5F0Su8MdPrH8WApPTHuKDANFOvoaBsc+sXBKgUW//fjN Mt87NGYrY3gUNL66WT8Qfl9BL9amkQmKmHNJXhsFgCbhhYZw3G/AF+cATbrO0Qj8jAEA tzhA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dmarc-filter :dkim-signature:dkim-signature:arc-authentication-results; bh=bZQv7UtxHRoqd3FrNRTVmBwT5zgZDonD/NKmcCesMAA=; b=UxCkmCckZot06seKcG2hvch948uBj/k8PnDqgq3GdeX055m0NVFqEaTOua9oNE/opr jZAunuj7gRQ6eA9ztJjp6x20A6z5OqLH/oqYVZI0UVsalI3U8ukzhYc37MEHogJM4NBr voADM+eJD/w12JFjc2PlfQ/ptoTQT5mNw9yany2yLhZNE/pWXQqYXV062Dg8TR0zlsii jeZk6AyXwwsdPDlMkdem3NFF3QYH8lji/3x5rulKqs0NXJ+AeFUju12r1B0IPzQhUrcV 5bjfyv+siRs1EeaniGDK7l7K8JnMa/palQYYrY6GyX7qvXkUo9JzHIaWreAM9YEpnFQK 5C3A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@codeaurora.org header.s=default header.b=KksBTMpx; dkim=pass header.i=@codeaurora.org header.s=default header.b=jwuQQXIf; 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 y12-v6si2653336plt.1.2018.02.12.09.43.25; Mon, 12 Feb 2018 09:43: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=@codeaurora.org header.s=default header.b=KksBTMpx; dkim=pass header.i=@codeaurora.org header.s=default header.b=jwuQQXIf; 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 S1752532AbeBLRmc (ORCPT + 99 others); Mon, 12 Feb 2018 12:42:32 -0500 Received: from smtp.codeaurora.org ([198.145.29.96]:58096 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751063AbeBLRmb (ORCPT ); Mon, 12 Feb 2018 12:42:31 -0500 Received: by smtp.codeaurora.org (Postfix, from userid 1000) id 274A660F71; Mon, 12 Feb 2018 17:42:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1518457351; bh=TZs+C0rClPBXgWzfufRQ4CGlxfWiK8gO9ThN38MNo0k=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=KksBTMpxp4bN9UffgvJDE3qtaXAU9iGNGcZu/vYoC1sma0lYn5d4g+ZQ25PsstQ4S FSpNDbN7BK+wR1maTlgEdd1WmNHYH8tZxok1XTGl9hIRfl553vRBzsbdF/To86yGG4 GsQ94LDNHkiB/7M1sJLYymjXqQdI1HH3CNy66+c8= 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 [10.134.64.46] (i-global254.qualcomm.com [199.106.103.254]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: rananta@smtp.codeaurora.org) by smtp.codeaurora.org (Postfix) with ESMTPSA id 6A3F960246; Mon, 12 Feb 2018 17:42:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1518457350; bh=TZs+C0rClPBXgWzfufRQ4CGlxfWiK8gO9ThN38MNo0k=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=jwuQQXIfn/meYDbOBvSW9tOC0NyH6+eW0sOViq2oco7Hn4g5HXLqrolGCBRqzqXpz XdlM3eQ5On6c2+fz2z3swlxWELFz8InlQRcsES+hRgZ9wo02hNgFAeEaydH3x6nJHR xQl6BfgDqp3DtwKsGA27Yvz94o2oXyXlG4lnPjz8= DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org 6A3F960246 Authentication-Results: pdx-caf-mail.web.codeaurora.org; dmarc=none (p=none dis=none) header.from=codeaurora.org Authentication-Results: pdx-caf-mail.web.codeaurora.org; spf=none smtp.mailfrom=rananta@codeaurora.org Subject: Re: [PATCH] perf: Add support for creating offline events To: Jiri Olsa Cc: peterz@infradead.org, mingo@redhat.com, acme@kernel.org, alexander.shishkin@linux.intel.com, namhyung@kernel.org, linux-kernel@vger.kernel.org, psodagud@codeaurora.org, tsoni@codeaurora.org References: <1518217620-28458-1-git-send-email-rananta@codeaurora.org> <20180212094357.GD5821@krava> From: Raghavendra Rao Ananta Message-ID: <53408020-8638-4947-90f6-87dbc4c2c4e5@codeaurora.org> Date: Mon, 12 Feb 2018 09:42:05 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <20180212094357.GD5821@krava> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Jiri, Thank you for the response. Does perf tool has its own check to see if the CPU was offline during the lifetime of an event? If so, it might ignore these type of events. Initially, I tested the same using perf tool and found similar results. Then I debugged further and found that the perf core was actually sending data to the userspace (copy_to_user()) and the corresponding count for the data. Hence, I tested this further by writing my own userspace application, and I was able to read the count through this, even when the CPU was made offline and back online. Do you think we also have to modify the perf tool accordingly? Find an inline comment. On 02/12/2018 01:43 AM, Jiri Olsa 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. >> >> Signed-off-by: Raghavendra Rao Ananta > > hum, I tried and for some reason I'm getting zero counts/times > when the cpu 1 is set back online (in 9.second) > > [root@ibm-x3650m4-02 perf]# ./perf stat -C 1 -e sched:sched_switch -v -I 1000 > failed to read counter sched:sched_switch > # time counts unit events > 1.000921624 sched:sched_switch > failed to read counter sched:sched_switch > 2.001725364 sched:sched_switch > failed to read counter sched:sched_switch > 3.002685350 sched:sched_switch > failed to read counter sched:sched_switch > 4.003463851 sched:sched_switch > failed to read counter sched:sched_switch > 5.004651601 sched:sched_switch > failed to read counter sched:sched_switch > 6.005338294 sched:sched_switch > failed to read counter sched:sched_switch > 7.006351155 sched:sched_switch > failed to read counter sched:sched_switch > 8.007239698 sched:sched_switch > sched:sched_switch: 0 0 0 > 9.008665621 sched:sched_switch > sched:sched_switch: 0 0 0 > 10.009570492 sched:sched_switch > sched:sched_switch: 0 0 0 > 11.010811591 sched:sched_switch > sched:sched_switch: 0 0 0 > 12.011614182 sched:sched_switch > sched:sched_switch: 0 0 0 > 13.012299851 sched:sched_switch > > looks like the dormant event wasn't scheduled in properly > > also while at it, could we also handle cpu going offline case, > so the event would survive until it's back online Sure, I have a plan for that one as well, but wondering how this goes first. > > jirka > Thank you. Raghavendra -- Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project