Received: by 2002:a25:683:0:0:0:0:0 with SMTP id 125csp2029852ybg; Fri, 5 Jun 2020 03:53:23 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzsnoWtDxYT5N+QJflYBMxXUwgiBUoNCH/dPDeSndDVIZjA4SWc4gxaudq8NPQ/T4jV2knj X-Received: by 2002:a17:906:48d8:: with SMTP id d24mr921385ejt.369.1591354402999; Fri, 05 Jun 2020 03:53:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1591354402; cv=none; d=google.com; s=arc-20160816; b=faYPh0bQBK7u2whOYJHaffPnXBeWjL1GvE+0VJvgoDL5QyNN2G3pWdkip5+oXPUjGR EBhFiwlHtPVzXt9JpAIlKWphM14VZ9d+Ku7P2fvlR8lQ2+F4MKxkvhh9RKBUMlhr4t7S TFhl6yCT7GeOgUPsSfHj4+cUgR14Nz6bdeOWnby3TPCvLiLYfNx+xOqYLXeqofjVL0MF nZgKuwxpU9WbZt6GON4JrE5c7f7tFvRd5fgvwPL6LYXYgOPiNwZy6sJXC2XWgyYXFMXs LP044blQvcBuXX/CBgDRommm61u9PIQzlbilPBsc0cEkuxAl97dnROYZyCIg0L+dajeB ZE2A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=jBPNXeumoB2edMU7rBwZo/XR6v1tVQAaNzjEQzvK0+w=; b=UhyRb4DaROa4AN/MXU5WiV1dfr98QSlJGSYcUReKaEeKvailtz1HaILUM5pHq+MQ/S 51kDof8SzDN7ouI26hp7o2QiKv5pSu1+XaM8/5iYEKUPG6GuHugRacXV/jjRl+cP96xU o042nxgW+h8/dRLcM/6zw5Q8qblAljHIlqXr3n8BY+x53Jm2vtStTdB0fn5250b3WWeg M0I8IEdynrxK5U1ru9hLP3vzsrGlPDBJcfaSkb+JHIouLe9+41s63MhrF4IA4paAcafF sGsolEDRkG/0CRkxlcrmWuLsMyqAsKadQPMP/Ti2VCB332jZhlgX3vQA3vw3txqJvrfw /X8Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=b5DprF4I; 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=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id qw23si3267310ejb.231.2020.06.05.03.53.00; Fri, 05 Jun 2020 03:53:22 -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; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=b5DprF4I; 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=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726875AbgFEKvC (ORCPT + 99 others); Fri, 5 Jun 2020 06:51:02 -0400 Received: from us-smtp-2.mimecast.com ([207.211.31.81]:51609 "EHLO us-smtp-delivery-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726637AbgFEKvB (ORCPT ); Fri, 5 Jun 2020 06:51:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1591354259; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=jBPNXeumoB2edMU7rBwZo/XR6v1tVQAaNzjEQzvK0+w=; b=b5DprF4IPtbaFPjIWiKXqEX47S+skBDeZGcCwabyJoGY1qsXD/vx0opsgJF2rUGHePIUsS PZ/miKW4z9Y6Iu7LbYctQzXauXd4M8lnkid43Cq5Oq10zfA7DVPXl68chOndKMbpHD8y5z apKJ3ZszqMKroR6DHNEcPynh6rEXKAU= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-145-avP1jYz7PEG9B5RZuDWbAA-1; Fri, 05 Jun 2020 06:50:56 -0400 X-MC-Unique: avP1jYz7PEG9B5RZuDWbAA-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id AA12D464; Fri, 5 Jun 2020 10:50:54 +0000 (UTC) Received: from krava (unknown [10.40.193.237]) by smtp.corp.redhat.com (Postfix) with SMTP id 85A72100238D; Fri, 5 Jun 2020 10:50:52 +0000 (UTC) Date: Fri, 5 Jun 2020 12:50:51 +0200 From: Jiri Olsa To: Alexey Budankov Cc: Arnaldo Carvalho de Melo , Namhyung Kim , Alexander Shishkin , Peter Zijlstra , Ingo Molnar , Andi Kleen , linux-kernel Subject: Re: [PATCH v7 01/13] tools/libperf: introduce notion of static polled file descriptors Message-ID: <20200605105051.GA1404794@krava> References: <5de4b954-24f0-1e8d-5a0d-7b12783b8218@linux.intel.com> <3c92a0ad-d7d3-4e78-f0b8-1d3a7122c69e@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3c92a0ad-d7d3-4e78-f0b8-1d3a7122c69e@linux.intel.com> X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 how about we make the 'pos indexes' being stable by allocating separate object for each added descriptor and each poll call would create pollfd array from current objects, and entries would keep pointer to its pollfd entry struct fdentry *entry { int fd; int events; struct pollfd *pollfd; } entry1 = fdarray__add(a, fd1 ...); entry2 = fdarray__add(a, fd2 ...); entry3 = fdarray__add(a, fd3 ...); fdarray__poll(a); struct pollfd *fdarray__entry_pollfd(a, entry1); or smoething like that ;-) jirka