Received: by 2002:a25:683:0:0:0:0:0 with SMTP id 125csp4244459ybg; Mon, 8 Jun 2020 02:56:51 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwhPIXtm63CpnsmdCXAlS9zTcGKbgJcgi/KQY0f4c86I3MXSZCi//LmNv5gU6Xndztel02d X-Received: by 2002:a50:fb14:: with SMTP id d20mr21098783edq.209.1591610211089; Mon, 08 Jun 2020 02:56:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1591610211; cv=none; d=google.com; s=arc-20160816; b=i/yYnejRdWMajbXutNXwW8hsaP7yUpDjhXomrsJ2+GxaLWuC0GHes1+trb7EYwYrpY ODfVk/eHt3JaKPk52B++C6s5NCQ5NT1WFkgr7++TwETnz9TXmsSFW/Whgte+Dy7A6nVn /lzm8M2Cene8SbZjz4eNFp5QjKsmMF7KpJ6PaqBy4jLkKEEtkOvRCTc9XWjlRSglfATt 0eKZBDyyqSNYlzVIgmg7/lVf0UOUK1/3gUJtP2n5Mq1tSomF77wQWeLxcHXSUJcJUSfQ R1tHJWClcLVLdGpdQ7CDPiqdyRbHXqE+ZzbMnzCBZByqsuUdBimk4XHLkW7SeA4Pecfb feZQ== 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=xg/CE6gsWuRjPtOMjouOLkNkcYEVsxmaDRVVTNgDIv8=; b=zilrkC117N6zqA01Sem9XqqmcWXj2q5JDr3aLdKw1Mk8NIBpvxgSZguOKzZw62+FPm 81wOFi0hjsUM2Kr3CJHNhg5mvPQCfz0oUKCgbdUILXVBJEu38mgv4GOSV6TU4TZe2Kl/ Ji1ODQ9VuOdnDmoH3FRt8I8kYcjTetJF3X/0xrxbWOwUyRoWRaOJV1LmsL+nrgPQ9xq6 N3MqGNpAlC0GOiiU1pj5XLKgUBfEsQqwdWG8QAoZNAwNjIn8T+N2QapLDn0gAF6bqBk4 miuBwY5TTvZWVIQQT6J2JdUEmBlQamCYJwN7dNudBZYwsBPOxycYHAaDlJYvMWJZAQ1O BGEQ== 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 dg18si8522238edb.211.2020.06.08.02.56.26; Mon, 08 Jun 2020 02:56:51 -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 S1729256AbgFHJyk (ORCPT + 99 others); Mon, 8 Jun 2020 05:54:40 -0400 Received: from mga09.intel.com ([134.134.136.24]:62656 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729166AbgFHJyj (ORCPT ); Mon, 8 Jun 2020 05:54:39 -0400 IronPort-SDR: YL67fm1fiCOnacuAhbYMxQgFCQJmBGO0gcyxk1dxjCkaad1d3r7h1rzqpSsE0r7tfF/4yDglAm 27gn/qnyMebA== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Jun 2020 02:54:37 -0700 IronPort-SDR: 9Foius5sJbXsVDgbWFtSdweaOHnchmnvTUjjdHVbDE/wRbGlq/J37h6nqZUdz74P8GF8iRZfNg UZmKIYDPJLYw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.73,487,1583222400"; d="scan'208";a="472636009" Received: from linux.intel.com ([10.54.29.200]) by fmsmga005.fm.intel.com with ESMTP; 08 Jun 2020 02:54:37 -0700 Received: from [10.249.230.149] (abudanko-mobl.ccr.corp.intel.com [10.249.230.149]) by linux.intel.com (Postfix) with ESMTP id 2DE09580675; Mon, 8 Jun 2020 02:54:32 -0700 (PDT) Subject: Re: [PATCH v7 01/13] tools/libperf: introduce notion of static polled file descriptors To: Jiri Olsa Cc: Arnaldo Carvalho de Melo , Namhyung Kim , Alexander Shishkin , Peter Zijlstra , Ingo Molnar , Andi Kleen , linux-kernel References: <5de4b954-24f0-1e8d-5a0d-7b12783b8218@linux.intel.com> <3c92a0ad-d7d3-4e78-f0b8-1d3a7122c69e@linux.intel.com> <20200605105051.GA1404794@krava> <20200605113834.GC1404794@krava> <49eca46e-4d0e-2ae5-d7d9-e37a4d680270@linux.intel.com> <20200608084344.GA1520715@krava> From: Alexey Budankov Organization: Intel Corp. Message-ID: <2d80a43a-54cf-3d12-92fd-066217c95d76@linux.intel.com> Date: Mon, 8 Jun 2020 12:54:31 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: <20200608084344.GA1520715@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 08.06.2020 11:43, Jiri Olsa wrote: > On Mon, Jun 08, 2020 at 11:08:56AM +0300, Alexey Budankov wrote: >> >> On 05.06.2020 19:15, Alexey Budankov wrote: >>> >>> On 05.06.2020 14:38, Jiri Olsa wrote: >>>> On Fri, Jun 05, 2020 at 12:50:54PM +0200, Jiri Olsa wrote: >>>>> On Wed, Jun 03, 2020 at 06:52:59PM +0300, Alexey Budankov wrote: >>>>>> >>>>>> Implement adding of file descriptors by fdarray__add_stat() to >>>>>> fix-sized (currently 1) stat_entries array located at struct fdarray. >>>>>> Append added file descriptors to the array used by poll() syscall >>>>>> during fdarray__poll() call. Copy poll() result of the added >>>>>> descriptors from the array back to the storage for analysis. >>>>>> >>>>>> Signed-off-by: Alexey Budankov >>>>>> --- >>>>>> tools/lib/api/fd/array.c | 42 +++++++++++++++++++++++- >>>>>> tools/lib/api/fd/array.h | 7 ++++ >>>>>> tools/lib/perf/evlist.c | 11 +++++++ >>>>>> tools/lib/perf/include/internal/evlist.h | 2 ++ >>>>>> 4 files changed, 61 insertions(+), 1 deletion(-) >>>>>> >>>>>> diff --git a/tools/lib/api/fd/array.c b/tools/lib/api/fd/array.c >>>>>> index 58d44d5eee31..b0027f2169c7 100644 >>>>>> --- a/tools/lib/api/fd/array.c >>>>>> +++ b/tools/lib/api/fd/array.c >>>>>> @@ -11,10 +11,16 @@ >>>>>> >>>>>> void fdarray__init(struct fdarray *fda, int nr_autogrow) >>>>>> { >>>>>> + int i; >>>>>> + >>>>>> fda->entries = NULL; >>>>>> fda->priv = NULL; >>>>>> fda->nr = fda->nr_alloc = 0; >>>>>> fda->nr_autogrow = nr_autogrow; >>>>>> + >>>>>> + fda->nr_stat = 0; >>>>>> + for (i = 0; i < FDARRAY__STAT_ENTRIES_MAX; i++) >>>>>> + fda->stat_entries[i].fd = -1; >>>>>> } >>>>>> >>>>>> int fdarray__grow(struct fdarray *fda, int nr) >>>>>> @@ -83,6 +89,20 @@ int fdarray__add(struct fdarray *fda, int fd, short revents) >>>>>> return pos; >>>>>> } >>>>>> >>>>>> +int fdarray__add_stat(struct fdarray *fda, int fd, short revents) >>>>>> +{ >>>>>> + int pos = fda->nr_stat; >>>>>> + >>>>>> + if (pos >= FDARRAY__STAT_ENTRIES_MAX) >>>>>> + return -1; >>>>>> + >>>>>> + fda->stat_entries[pos].fd = fd; >>>>>> + fda->stat_entries[pos].events = revents; >>>>>> + fda->nr_stat++; >>>>>> + >>>>>> + return pos; >>>>>> +} >>>>>> + >>>>>> int fdarray__filter(struct fdarray *fda, short revents, >>>>>> void (*entry_destructor)(struct fdarray *fda, int fd, void *arg), >>>>>> void *arg) >>>>>> @@ -113,7 +133,27 @@ int fdarray__filter(struct fdarray *fda, short revents, >>>>>> >>>>>> int fdarray__poll(struct fdarray *fda, int timeout) >>>>>> { >>>>>> - return poll(fda->entries, fda->nr, timeout); >>>>>> + int nr, i, pos, res; >>>>>> + >>>>>> + nr = fda->nr; >>>>>> + >>>>>> + for (i = 0; i < fda->nr_stat; i++) { >>>>>> + if (fda->stat_entries[i].fd != -1) { >>>>>> + pos = fdarray__add(fda, fda->stat_entries[i].fd, >>>>>> + fda->stat_entries[i].events); >>>>> >>>>> so every call to fdarray__poll will add whatever is >>>>> in stat_entries to entries? how is it removed? >>>>> >>>>> I think you should either follow what Adrian said >>>>> and put 'static' descriptors early and check for >>>>> filter number to match it as an 'quick fix' >>>>> >>>>> or we should fix it for real and make it generic >>>>> >>>>> so currently the interface is like this: >>>>> >>>>> pos1 = fdarray__add(a, fd1 ... ); >>>>> pos2 = fdarray__add(a, fd2 ... ); >>>>> pos3 = fdarray__add(a, fd2 ... ); >>>>> >>>>> fdarray__poll(a); >>>>> >>>>> num = fdarray__filter(a, revents, destructor, arg); >>>>> >>>>> when fdarray__filter removes some of the fds the 'pos1,pos2,pos3' >>>>> indexes are not relevant anymore >>> >>> and that is why the return value of fdarray__add() should be converted >>> to bool (added/not added). Currently the return value is used as bool >>> only allover the calling code. >>> >>> fdarray__add_fixed() brings the notion of fd with fixed pos which is >>> valid after fdarray__add_fixed() call so the pos could be used to access >>> pos fd poll status after poll() call. >>> >>> pos = fdarray__add_fixed(array, fd); >>> fdarray_poll(array); >>> revents = fdarray_fixed_revents(array, pos); >>> fdarray__del(array, pos); >> >> So how is it about just adding _revents() and _del() for fixed fds with >> correction of retval to bool for fdarray__add()? > > I don't like the separation for fixed and non-fixed fds, > why can't we make generic? Usage models are different but they want still to be parts of the same class for atomic poll(). The distinction is filterable vs. not filterable. The distinction should be somehow provided in API. Options are: 1. expose separate API calls like __add_nonfilterable(), __del_nonfilterable(); use nonfilterable quality in __filter() and __poll() and, perhaps, other internals; 2. extend fdarray__add(, nonfilterable) with the nonfilterable quality use the type in __filter() and __poll() and, perhaps, other internals; expose less API calls in comparison with option 1 Exposure of pos for filterable fds should be converted to bool since currently the returned pos can become stale and there is no way in API to check its state. So it could look like this: fdkey = fdarray__add(array, fd, events, type) type: filterable, nonfilterable, somthing else revents = fdarray__get_revents(fdkey); fdarray__del(array, fdkey); ~Alexey