Received: by 2002:a25:683:0:0:0:0:0 with SMTP id 125csp479187ybg; Wed, 3 Jun 2020 05:58:03 -0700 (PDT) X-Google-Smtp-Source: ABdhPJztc8J1RlWGqs+2h3HM7pPcELDGOFyE5FV8FZhMKqhtk/l7eHUJKMbr9AIWDv9nZqXswlcr X-Received: by 2002:a05:6402:1d89:: with SMTP id dk9mr18825023edb.275.1591189083217; Wed, 03 Jun 2020 05:58:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1591189083; cv=none; d=google.com; s=arc-20160816; b=zh/l9BXcfEkPC8X+wahn/GkIOXWWUSyGs3GmKLzw/nwMyNMbI9Pr2nqqUmK5x4BrTN rotx2v07AojklUwoPCN+aSbLreGRu+WECaJFjR6zSk1PmTRFVSHl5jIV2qfFZDEcG99E VNapnOMsdb1DS2cd1Z9/7Ez6/373t6g/02eaz0wsPMhIXBQa3nn6E1C1vjfbfRxy6Ryb vyzE1D94S3ny4qbFcH/+HXmVYlnn2q4K4pRgDvvn8EOcejBIpBeu7AArfj6JKuZUXBXt pOnKALS8dHqp6SNsItZLbsh2QFYUpJztT5b9caZgonBtLKOUdJLL/l+oECxGLMxf6kjl 2Lvg== 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=HjJvJrXg24B+mxBSefm6zkDoKmngusfjx9nDGq3UR20=; b=FI9mT1O13P8goFuqj6/ZGPuUr1k2jvpUwPOmySX9P1Z1QObETQqlJ4VjOMcIU7cETk 3b6shc23wQ2EOsucKmWi+TZkwi3rYfUT4Zb+eLfGrKd5iC5S6V5B+c9+XwlgPxC5eY5o 6/eITkErPEjaPDdmdTPlMTXE4S4AfjVW3ZO59+3A7dzZ8w9I9+cmJSj2n8ljPRdG2Jv9 KyLSfTFwnW5ScvRKN/ybeFvtZDqUGsWJgm0ouurzTTaL2mvThoHMbpEKpbjUqdulC0UV W+NSH8hfQ5vMd3mcsUq4HNPKaYcgpgjx9PFAw4qvSNosEvefU0//b0KrFoTypewkQl2q IZ5A== 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 y30si1185911edi.11.2020.06.03.05.57.39; Wed, 03 Jun 2020 05:58:03 -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 S1726077AbgFCMw6 (ORCPT + 99 others); Wed, 3 Jun 2020 08:52:58 -0400 Received: from mga02.intel.com ([134.134.136.20]:60598 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725948AbgFCMw6 (ORCPT ); Wed, 3 Jun 2020 08:52:58 -0400 IronPort-SDR: W8sT9l4vLhx0faDrhVWwsdnWzwe2gz3vNjZbcovkYnXg4k8VIl9LqW7oWmx01kyYF0GuNSTYZq VqQJX55/U/TA== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Jun 2020 05:52:57 -0700 IronPort-SDR: sFZ3MGew3Vqfg9eamgBCc3HZUf9hTlBph9ic9x/Et2eMKwG9uEY2c/EnJVD04Lwl6aoesmawG+ zI6f1fKxsxhg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.73,467,1583222400"; d="scan'208";a="312599731" Received: from linux.intel.com ([10.54.29.200]) by FMSMGA003.fm.intel.com with ESMTP; 03 Jun 2020 05:52:57 -0700 Received: from [10.249.225.188] (abudanko-mobl.ccr.corp.intel.com [10.249.225.188]) by linux.intel.com (Postfix) with ESMTP id 10E4E5800E3; Wed, 3 Jun 2020 05:52:54 -0700 (PDT) Subject: Re: [PATCH v6 01/13] tools/libperf: introduce notion of static polled file descriptors To: "Hunter, Adrian" Cc: Arnaldo Carvalho de Melo , Jiri Olsa , Namhyung Kim , Alexander Shishkin , Peter Zijlstra , Ingo Molnar , Andi Kleen , linux-kernel References: <40643542-6676-e0bc-2d10-165dfde41e29@linux.intel.com> <33c91520-7040-bd6b-b176-004ddbec2a63@intel.com> <363DA0ED52042842948283D2FC38E464B4151F86@IRSMSX106.ger.corp.intel.com> From: Alexey Budankov Organization: Intel Corp. Message-ID: <40d44cd8-ecdb-53c9-99f8-1737e04c84ff@linux.intel.com> Date: Wed, 3 Jun 2020 15:52:53 +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: <363DA0ED52042842948283D2FC38E464B4151F86@IRSMSX106.ger.corp.intel.com> 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 03.06.2020 15:30, Hunter, Adrian wrote: > > >> -----Original Message----- >> From: Hunter, Adrian >> Sent: Wednesday, June 3, 2020 3:24 PM >> To: Alexey Budankov >> Cc: Arnaldo Carvalho de Melo ; Jiri Olsa >> ; Namhyung Kim ; Alexander >> Shishkin ; Peter Zijlstra >> ; Ingo Molnar ; Andi Kleen >> ; linux-kernel >> Subject: Re: [PATCH v6 01/13] tools/libperf: introduce notion of static polled >> file descriptors >> >> On 3/06/20 3:01 pm, Alexey Budankov wrote: >>> Hi, >>> >>> On 03.06.2020 14:38, Adrian Hunter wrote: >>>> On 1/06/20 11:05 pm, 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 separate analysis. >>>> >>>> Why not instead call evlist__add_pollfd() before other fds are added, >>>> so the fda->entries[] position is always fixed. Then this patch is not >> needed. >>> >>> It then will block event consumption loop, at least in record mode, >>> due to change sin initial assumptions behind fdarray__filter(). So >>> extension of the API with 'static' fds looks safer w.r.t. possible >>> functional regressions at the same time extending the API with ability >>> to atomically wait for (poll()) not only event fds but also any other fds >> during monitoring. >> >> So make fdarray__filter() return the number of filterable fds remaining. >> > > > Or perhaps simpler, compare the return value to the number of fds that are known not to be filterable Well, various implementations are for sure possible but the proposed design avoids implicit code assumptions and dependency on API calls order as in API implementation as in client code and that is why it's been proposed this way.