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;
Date:   Mon, 29 Jun 2020 21:17:00 +0200
From:   Jiri Olsa <jolsa@redhat.com>
To:     Alexey Budankov <alexey.budankov@linux.intel.com>
Cc:     Arnaldo Carvalho de Melo <acme@kernel.org>,
        Namhyung Kim <namhyung@kernel.org>,
        Alexander Shishkin <alexander.shishkin@linux.intel.com>,
        Peter Zijlstra <peterz@infradead.org>,
        Ingo Molnar <mingo@redhat.com>,
        Andi Kleen <ak@linux.intel.com>,
        linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v8 01/13] tools/libperf: avoid moving of fds at
 fdarray__filter() call
Message-ID: <20200629191700.GC3031756@krava>
References: <0781a077-aa82-5b4a-273e-c17372a72b93@linux.intel.com>
 <3d36dc7a-4249-096c-7554-80e6d290eac5@linux.intel.com>
 <fada6325-2e6a-0de4-918f-0bc7d1410c52@linux.intel.com>
 <20200625171405.GL2719003@krava>
 <688910f3-289e-d63e-79e3-0a17a6df0e9e@linux.intel.com>
 <20200626093745.GM2719003@krava>
 <6582201a-9570-709f-f6e9-5a644296f49d@linux.intel.com>
 <b2a868bb-b434-7814-d577-944efc5369aa@linux.intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <b2a868bb-b434-7814-d577-944efc5369aa@linux.intel.com>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Mon, Jun 29, 2020 at 06:11:52PM +0300, Alexey Budankov wrote:

SNIP

> >>
> >> I'm confused, are you talking about file descriptors limit now?
> >> this wont be affected by epoll change.. what do I miss?
> > 
> > Currently there is already uname -n limit on the amount of open file descriptors
> > and Perf tool process is affected by that limit.
> > 
> > Moving to epoll() will impose one more max_user_watches limit and that can additionally
> > confine Perf applicability even though default value on some machines currently
> > is high enough.
> 
> Prior making v9 I would prefer to agree on some design to be implemented in order to
> avoid guessing and redundant reiterating.
> 
> Options that I see as good balanced ones are 1) or 5), + non screwing of fds to fix
> staleness of pos(=fdarray__add()).
> 
> Are there any thoughts so far?

let's try it and discuss over the code

jirka