Received: by 2002:a25:868d:0:0:0:0:0 with SMTP id z13csp756459ybk; Wed, 20 May 2020 11:09:42 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyBHSOQy2CtodIIIDbQmOqNctmhBPgSwDzCHrPc7tSyCYZsgXv5UapsI4nu2eIzWpjoCrxA X-Received: by 2002:a17:906:944c:: with SMTP id z12mr271037ejx.472.1589998182408; Wed, 20 May 2020 11:09:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1589998182; cv=none; d=google.com; s=arc-20160816; b=UWTd3+TMr9V8ek3/6yeOdhdgQ0ugUR+IjhkjjS5UTZpP3np+GoorKTa3jJqMi175gt c/Zpclgc7pWnlt5ZH25IdhyCD+6qEiDtU27YOqDEfybT3wKuC1onV6iNC6Ape2V9tSPl omrr4/uRytl3WpuW8jiSx52cpCBh9A1yF9WeZzIAkS1L/RwkY78Wt3u7EClAL1ai59Wu ZrgX3i+qhFnQqAw9WTvCxpWZjKyJtiJk60skvwIhlOjWC8UFqOvgu9I0LHHLCGfYxDHS M7NMjxcRf2l+ylImdOaswRNRrYuYlNK40Sx/FknYdYWT5YkggehhGWBSl6uFyzDUNLHL 3Heg== 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:organization:from:references:cc:to:subject:ironport-sdr :ironport-sdr; bh=bg/7rRPjmeTrZZTamLmoad136QztH6l4J4xrXgA9sFM=; b=hZxFaJGLqkXyCFVXyDcQ7y/dgYepUWxmDp+2T+bCoBwjpISkTa2DaaPq+AuOkC+5hZ UjBYLli1GEYySrRjQOSE9hjfNFbZR1ArxpqgmgfT6e0rkyLAHumul0o7xVfcLiftagjo MpLDa3qPw7XEz91GHwClP4MydV7TkHZ1uRb7D5Pdk06LBYX358q3IK6F+0lxggSkY1cw WwOOGsEWWXLduWFw3iQFaJECvgR1P0NlYLQuHMUIhbEshxGGEAHYXTyssql805uGLXn4 Dec3pFJ2+EIKuRrGoLNuYgJBHRJVUYIk52dimLob8Moas2eE2prSJZIWtnt4ENlgxlhF 8onA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id sa22si2254532ejb.8.2020.05.20.11.09.18; Wed, 20 May 2020 11:09:42 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726984AbgETSGz (ORCPT + 99 others); Wed, 20 May 2020 14:06:55 -0400 Received: from mga01.intel.com ([192.55.52.88]:47203 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726964AbgETSGy (ORCPT ); Wed, 20 May 2020 14:06:54 -0400 IronPort-SDR: CYh3q2d11wKl5AfaRMqB3l8bSMmjXNbKahiHqHB2GFd+3QzrubrCjl2zlhE5jBRgeg3vlRSgLL MFApj09NAN9w== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga006.jf.intel.com ([10.7.209.51]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 May 2020 11:06:53 -0700 IronPort-SDR: y4TAj5LuH/3XDp/qr/BXcqJuuf3jzmX8mc87XEewhYq9zb08w8kkZbOUihK3Msf4wb8K7inFvA nUWpA3oj1dRg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.73,414,1583222400"; d="scan'208";a="268351859" Received: from linux.intel.com ([10.54.29.200]) by orsmga006.jf.intel.com with ESMTP; 20 May 2020 11:06:53 -0700 Received: from [10.249.231.6] (abudanko-mobl.ccr.corp.intel.com [10.249.231.6]) by linux.intel.com (Postfix) with ESMTP id CD19B580100; Wed, 20 May 2020 11:06:50 -0700 (PDT) Subject: Re: [PATCH v3 8/9] perf record: implement control commands handling To: Jiri Olsa Cc: Arnaldo Carvalho de Melo , Namhyung Kim , Alexander Shishkin , Peter Zijlstra , Ingo Molnar , Andi Kleen , linux-kernel References: <25f98682-5ef2-4257-f302-93b29da707a9@linux.intel.com> <20200520123833.GG157452@krava> From: Alexey Budankov Organization: Intel Corp. Message-ID: Date: Wed, 20 May 2020 21:06:49 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <20200520123833.GG157452@krava> Content-Type: text/plain; charset=utf-8 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 On 20.05.2020 15:38, Jiri Olsa wrote: > On Wed, May 13, 2020 at 11:04:25AM +0300, Alexey Budankov wrote: >> >> Implement handling of 'enable' and 'disable' control commands >> coming from control file descriptor. >> >> Signed-off-by: Alexey Budankov >> --- >> tools/perf/builtin-record.c | 18 +++++++++++++++++- >> 1 file changed, 17 insertions(+), 1 deletion(-) >> >> diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c >> index 50dc2fe626e5..72f388623364 100644 >> --- a/tools/perf/builtin-record.c >> +++ b/tools/perf/builtin-record.c >> @@ -1505,6 +1505,7 @@ static int __cmd_record(struct record *rec, int argc, const char **argv) >> bool disabled = false, draining = false; >> int fd; >> float ratio = 0; >> + enum evlist_ctl_cmd cmd = EVLIST_CTL_CMD_UNSUPPORTED; >> >> atexit(record__sig_exit); >> signal(SIGCHLD, sig_handler); >> @@ -1802,8 +1803,23 @@ static int __cmd_record(struct record *rec, int argc, const char **argv) >> * Propagate error, only if there's any. Ignore positive >> * number of returned events and interrupt error. >> */ >> - if (err > 0 || (err < 0 && errno == EINTR)) >> + if (err > 0 || (err < 0 && errno == EINTR)) { >> err = 0; >> + if (evlist__ctlfd_process(rec->evlist, &cmd) > 0) { >> + switch (cmd) { >> + case EVLIST_CTL_CMD_ENABLE: >> + pr_info(EVLIST_ENABLED_MSG); >> + break; >> + case EVLIST_CTL_CMD_DISABLE: >> + pr_info(EVLIST_DISABLED_MSG); >> + break; >> + case EVLIST_CTL_CMD_ACK: >> + case EVLIST_CTL_CMD_UNSUPPORTED: >> + default: >> + break; >> + } >> + } >> + } > > so this will be processed only when: > > if (hits == rec->samples) { > > what if there's always somethign in the buffer? will this stall? > >> waking++; >> >> if (evlist__filter_pollfd(rec->evlist, POLLERR | POLLHUP) == 0) > > evlist__filter_pollfd will trigger draining if all the maps are closed, > but there's one more fd in pollfd now, will this prevent draining? Good catch. This needs redesign to notice pending commands during active trace streaming. The same is regarding draining. > > I wonder this would fit better to the sideband thread (util/sideband_evlist.c) > so we don't disturb the main thread with another check ~Alexey