On Tue, Aug 11, 2020 at 07:21:13PM +0300, Alexander Shishkin wrote:
> Andi Kleen writes:
>
> > On Tue, Aug 11, 2020 at 12:47:24PM +0300, Alexander Shishkin wrote:
> >>
> >> Right, but which bytes? One byte per event? That's
> >> arbitrary. sizeof(struct perf_event)? Then, probably also sizeof(st
> On Tue, Aug 11, 2020 at 02:47:03PM +, David Laight wrote:
> > From: Andi Kleen
> > > On Mon, Aug 10, 2020 at 10:36:32PM +0200, Peter Zijlstra wrote:
> > > > On Mon, Aug 10, 2020 at 07:45:18AM -0700, Andi Kleen wrote:
> > > >
> > > > > Unfortunately we're kind of stuck with the old NFILE=1024
On Tue, Aug 11, 2020 at 02:47:03PM +, David Laight wrote:
> From: Andi Kleen
> > On Mon, Aug 10, 2020 at 10:36:32PM +0200, Peter Zijlstra wrote:
> > > On Mon, Aug 10, 2020 at 07:45:18AM -0700, Andi Kleen wrote:
> > >
> > > > Unfortunately we're kind of stuck with the old NFILE=1024 default
> >
Andi Kleen writes:
> On Tue, Aug 11, 2020 at 12:47:24PM +0300, Alexander Shishkin wrote:
>>
>> Right, but which bytes? One byte per event? That's
>> arbitrary. sizeof(struct perf_event)? Then, probably also sizeof(struct
>> perf_event_context).
>
> Yes the sum of all the sizeofs needed for a per
From: Andi Kleen
> On Mon, Aug 10, 2020 at 10:36:32PM +0200, Peter Zijlstra wrote:
> > On Mon, Aug 10, 2020 at 07:45:18AM -0700, Andi Kleen wrote:
> >
> > > Unfortunately we're kind of stuck with the old NFILE=1024 default
> > > even though it makes little sense on modern servers.
> >
> > Why can't
On Mon, Aug 10, 2020 at 10:36:32PM +0200, Peter Zijlstra wrote:
> On Mon, Aug 10, 2020 at 07:45:18AM -0700, Andi Kleen wrote:
>
> > Unfortunately we're kind of stuck with the old NFILE=1024 default
> > even though it makes little sense on modern servers.
>
> Why can't that be changed? It seems to
On Tue, Aug 11, 2020 at 12:47:24PM +0300, Alexander Shishkin wrote:
> Andi Kleen writes:
>
> >> It didn't. I can't figure out what to charge on the locked memory, as
> >> all that memory is in kernel-side objects. It also needs to make sense
> >
> > I don't see how that makes a difference for the
Andi Kleen writes:
>> It didn't. I can't figure out what to charge on the locked memory, as
>> all that memory is in kernel-side objects. It also needs to make sense
>
> I don't see how that makes a difference for the count. It just account
> bytes. Can you elaborate?
Right, but which bytes? One
On 10.08.2020 23:36, Peter Zijlstra wrote:
> On Mon, Aug 10, 2020 at 07:45:18AM -0700, Andi Kleen wrote:
>
>> Unfortunately we're kind of stuck with the old NFILE=1024 default
>> even though it makes little sense on modern servers.
>
> Why can't that be changed? It seems to me all of userspace
On Mon, Aug 10, 2020 at 07:45:18AM -0700, Andi Kleen wrote:
> Unfortunately we're kind of stuck with the old NFILE=1024 default
> even though it makes little sense on modern servers.
Why can't that be changed? It seems to me all of userspace changes all
the time; heck that system-doofus thing flu
> It didn't. I can't figure out what to charge on the locked memory, as
> all that memory is in kernel-side objects. It also needs to make sense
I don't see how that makes a difference for the count. It just account
bytes. Can you elaborate?
> as iirc the default MLOCK_LIMIT is quite low, you'd h
Andi Kleen writes:
>> > This adds an opt-in flag to the perf_event_open() syscall to retain
>> > sibling events after their file descriptors are closed. In this case, the
>> > actual events will be closed with the group leader.
>>
>> So having the 1:1 re
On 07.08.20 18:23, Al Viro wrote:
Hi,
>> This is a concept from Plan9. The main purpose is allowing applications
>> "dialing" some connection, do initial handshakes (eg. authentication)
>> and then publish the connection to other applications, that now can now
>> make use of the already dialed co
On Fri, Aug 07, 2020 at 01:09:30PM +0200, Enrico Weigelt, metux IT consult
wrote:
> Hello folks,
>
>
> here's the first version of my "srvfs" implementation - a synthentic
> filesystem which allows a process to "publish" an open file descriptor
> into the file system, so other processes can cont
Hello folks,
here's the first version of my "srvfs" implementation - a synthentic
filesystem which allows a process to "publish" an open file descriptor
into the file system, so other processes can continue from there, with
whatever state the fd is already in.
This is a concept from Plan9. The m
> > This adds an opt-in flag to the perf_event_open() syscall to retain
> > sibling events after their file descriptors are closed. In this case, the
> > actual events will be closed with the group leader.
>
> So having the 1:1 relation with filedesc imposes a resou
On Thu, Aug 06, 2020 at 09:15:08AM +0300, Adrian Hunter wrote:
> On 8/07/20 6:16 pm, Alexander Shishkin wrote:
> > Hi guys,
> >
> > I've been looking at reducing the number of open file descriptors per perf
> > session. If we retain one descriptor per event, in a
On Wed, Jul 08, 2020 at 06:16:34PM +0300, Alexander Shishkin wrote:
> Currently, perf requires one file descriptor per event. In large groups,
> this may mean running into the limit on open file descriptors. However,
> the sibling events in a group only need file descriptors for th
On 8/07/20 6:16 pm, Alexander Shishkin wrote:
> Hi guys,
>
> I've been looking at reducing the number of open file descriptors per perf
> session. If we retain one descriptor per event, in a large group they add
> up. At the same time, we're not actually using th
Define and initialize control file descriptors.
Signed-off-by: Alexey Budankov
Acked-by: Jiri Olsa
Acked-by: Namhyung Kim
---
tools/perf/util/evlist.c | 3 +++
tools/perf/util/evlist.h | 5 +
2 files changed, 8 insertions(+)
diff --git a/tools/perf/util/evlist.c b/tools/perf/util
Define and initialize control file descriptors.
Signed-off-by: Alexey Budankov
---
tools/perf/util/evlist.c | 3 +++
tools/perf/util/evlist.h | 5 +
2 files changed, 8 insertions(+)
diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
index bcbe0cb8482e..36eb50aba1f5 100644
On 13.07.2020 6:13, Namhyung Kim wrote:
> Hello,
>
> On Wed, Jul 8, 2020 at 4:47 PM Alexey Budankov
> wrote:
>>
>>
>> Define and initialize control file descriptors.
>>
>> Signed-off-by: Alexey Budankov
>> ---
>> tools/perf/util/evlist.
Hello,
On Wed, Jul 8, 2020 at 4:47 PM Alexey Budankov
wrote:
>
>
> Define and initialize control file descriptors.
>
> Signed-off-by: Alexey Budankov
> ---
> tools/perf/util/evlist.c | 3 +++
> tools/perf/util/evlist.h | 5 +
> 2 files changed, 8 insertions(+)
Hi Alex,
On 08.07.2020 18:16, Alexander Shishkin wrote:
> Hi guys,
>
> I've been looking at reducing the number of open file descriptors per perf
> session. If we retain one descriptor per event, in a large group they add
> up. At the same time, we're not actually usin
On Wed, Jul 08, 2020 at 06:16:35PM +0300, Alexander Shishkin wrote:
> This changes perf record to close siblings' file descriptors after they
> are created, to reduce the number of open files. The trick is setting up
> mappings and applying ioctls to these guys before they get
Currently, perf requires one file descriptor per event. In large groups,
this may mean running into the limit on open file descriptors. However,
the sibling events in a group only need file descriptors for the initial
configuration stage, after which they may not be needed any more.
This adds an
This changes perf record to close siblings' file descriptors after they
are created, to reduce the number of open files. The trick is setting up
mappings and applying ioctls to these guys before they get closed, which
means a slight rework to allow these things to happen in the same loop as
Hi guys,
I've been looking at reducing the number of open file descriptors per perf
session. If we retain one descriptor per event, in a large group they add
up. At the same time, we're not actually using them for anything after the
SET_OUTPUT and maybe SET_FILTER ioctls. So, this s
Define and initialize control file descriptors.
Signed-off-by: Alexey Budankov
---
tools/perf/util/evlist.c | 3 +++
tools/perf/util/evlist.h | 5 +
2 files changed, 8 insertions(+)
diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
index bcbe0cb8482e..36eb50aba1f5 100644
Define and initialize control file descriptors.
Signed-off-by: Alexey Budankov
---
tools/perf/util/evlist.c | 3 +++
tools/perf/util/evlist.h | 5 +
2 files changed, 8 insertions(+)
diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
index 7b1beffec6a1..ee545a122b52 100644
On Mon, Jun 22, 2020 at 05:04:21PM +0300, Alexey Budankov wrote:
SNIP
> > there might be some loose ends (interface change), but
> > I think this would solve our problems with fdarray
>
> Your first patch accomodated in v8 actually avoids fds typing
> and solves pos (=fdarr
;>>>>
>>>>> no idea.. looking for good solution ;-)
>>>>>
>>>>> how about switching completely to epoll? I tried and it
>>>>> does not look that bad
>>>>
>>>> Well, epoll() is perhaps possible but
gt;>> how about switching completely to epoll? I tried and it
> >>> does not look that bad
> >>
> >> Well, epoll() is perhaps possible but why does it want switching to
> >> epoll()?
> >> What are the benefits and/or specific task being solved by t
to epoll()?
>> What are the benefits and/or specific task being solved by this switch?
>
> epoll change fixes the same issues as the patch you took in v8
>
> on top of it it's not a hack and wil make polling more user
> friendly because of the clear interface
Clear. Th
On Mon, Jun 22, 2020 at 12:47:19PM +0300, Alexey Budankov wrote:
SNIP
> >> fdarray__del(array, fdkey);
> >
> > I think there's solution without having filterable type,
> > I'm not sure why you think this is needed
> >
> > I'm busy with other things this week, but I think I
On 15.06.2020 19:58, Jiri Olsa wrote:
> On Mon, Jun 15, 2020 at 05:37:53PM +0300, Alexey Budankov wrote:
>>
>> On 15.06.2020 15:30, Jiri Olsa wrote:
>>> On Mon, Jun 15, 2020 at 08:20:38AM +0300, Alexey Budankov wrote:
On 08.06.2020 19:07, Jiri Olsa wrote:
> On Mon, Jun 08, 2020 at 12:
On 17.06.2020 12:27, Jiri Olsa wrote:
> On Mon, Jun 15, 2020 at 06:58:04PM +0200, Jiri Olsa wrote:
>> On Mon, Jun 15, 2020 at 05:37:53PM +0300, Alexey Budankov wrote:
>>>
>>> On 15.06.2020 15:30, Jiri Olsa wrote:
On Mon, Jun 15, 2020 at 08:20:38AM +0300, Alexey Budankov wrote:
>
> On
On Mon, Jun 15, 2020 at 06:58:04PM +0200, Jiri Olsa wrote:
> On Mon, Jun 15, 2020 at 05:37:53PM +0300, Alexey Budankov wrote:
> >
> > On 15.06.2020 15:30, Jiri Olsa wrote:
> > > On Mon, Jun 15, 2020 at 08:20:38AM +0300, Alexey Budankov wrote:
> > >>
> > >> On 08.06.2020 19:07, Jiri Olsa wrote:
> >
Define and initialize control file descriptors.
Signed-off-by: Alexey Budankov
---
tools/perf/util/evlist.c | 3 +++
tools/perf/util/evlist.h | 5 +
2 files changed, 8 insertions(+)
diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
index 173b4f0e0e6e..47541b5cab46 100644
On 09.06.2020 17:56, Jiri Olsa wrote:
> On Mon, Jun 08, 2020 at 08:18:20PM +0300, Alexey Budankov wrote:
>
> SNIP
>
>
> another idea is to forbid filter to screw the array
> and return only remaining number, like below
>
> jirka
>
>
> ---
> diff --git a/tools/lib/api/fd/array.c b/tools/l
On Mon, Jun 15, 2020 at 05:37:53PM +0300, Alexey Budankov wrote:
>
> On 15.06.2020 15:30, Jiri Olsa wrote:
> > On Mon, Jun 15, 2020 at 08:20:38AM +0300, Alexey Budankov wrote:
> >>
> >> On 08.06.2020 19:07, Jiri Olsa wrote:
> >>> On Mon, Jun 08, 2020 at 12:54:31PM +0300, Alexey Budankov wrote:
> >
On 15.06.2020 15:30, Jiri Olsa wrote:
> On Mon, Jun 15, 2020 at 08:20:38AM +0300, Alexey Budankov wrote:
>>
>> On 08.06.2020 19:07, Jiri Olsa wrote:
>>> On Mon, Jun 08, 2020 at 12:54:31PM +0300, Alexey Budankov wrote:
On 08.06.2020 11:43, Jiri Olsa wrote:
> On Mon, Jun 08, 2020 at 1
On 09.06.2020 17:56, Jiri Olsa wrote:
> On Mon, Jun 08, 2020 at 08:18:20PM +0300, Alexey Budankov wrote:
>
> SNIP
>
>>> 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
On Mon, Jun 15, 2020 at 08:20:38AM +0300, Alexey Budankov wrote:
>
> On 08.06.2020 19:07, Jiri Olsa wrote:
> > On Mon, Jun 08, 2020 at 12:54:31PM +0300, Alexey Budankov wrote:
> >>
> >> On 08.06.2020 11:43, Jiri Olsa wrote:
> >>> On Mon, Jun 08, 2020 at 11:08:56AM +0300, Alexey Budankov wrote:
> >
On 08.06.2020 19:07, Jiri Olsa wrote:
> On Mon, Jun 08, 2020 at 12:54:31PM +0300, Alexey Budankov wrote:
>>
>> 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
On 09.06.2020 17:56, Jiri Olsa wrote:
> On Mon, Jun 08, 2020 at 08:18:20PM +0300, Alexey Budankov wrote:
>
> SNIP
>
>>> 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
On Mon, Jun 08, 2020 at 08:18:20PM +0300, Alexey Budankov wrote:
SNIP
> > 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
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:
>
020 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:
>>>>
t; 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 des
i 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_sta
iri 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 st
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 t
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
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 (curren
On 05.06.2020 13:50, 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 fi
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.
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
> durin
sday, 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
>>>>
ldo 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
>>> f
Define and initialize control file descriptors.
Signed-off-by: Alexey Budankov
---
tools/perf/util/evlist.c | 3 +++
tools/perf/util/evlist.h | 5 +
2 files changed, 8 insertions(+)
diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
index 173b4f0e0e6e..47541b5cab46 100644
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
hishkin ; 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
; 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:
> >
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 a
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 descriptor
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()
Define and initialize control file descriptors.
Signed-off-by: Alexey Budankov
---
tools/perf/util/evlist.c | 3 +++
tools/perf/util/evlist.h | 5 +
2 files changed, 8 insertions(+)
diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
index 173b4f0e0e6e..47541b5cab46 100644
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
Define and initialize control file descriptors.
Signed-off-by: Alexey Budankov
---
tools/perf/util/evlist.c | 3 +++
tools/perf/util/evlist.h | 5 +
2 files changed, 8 insertions(+)
diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
index 173b4f0e0e6e..47541b5cab46 100644
Implement adding of file descriptors to fixed size (currently 1)
storage at struct fdarray by the dedicated fdarray__add_stat().
Index returned by fdarray__add_stat() is allocated once and unique
thus can safely be used to directly access entry at stat_entries.
Append the static descriptors to
On 31.05.2020 21:19, Jiri Olsa wrote:
> On Mon, May 25, 2020 at 05:17:31PM +0300, Alexey Budankov wrote:
>
> SBIP
>
>> +int fdarray__add_stat(struct fdarray *fda, int fd, short revents)
>> +{
>> +int pos = fda->nr_stat;
>> +
>> +if (pos >= FDARRAY__STAT_ENTRIES_MAX)
>> +retu
On Mon, May 25, 2020 at 05:17:31PM +0300, Alexey Budankov wrote:
SBIP
> +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;
The test_map_rdonly and test_map_wronly tests should close file descriptors
which they open.
Signed-off-by: Anton Protopopov
---
tools/testing/selftests/bpf/test_maps.c | 4
1 file changed, 4 insertions(+)
diff --git a/tools/testing/selftests/bpf/test_maps.c
b/tools/testing/selftests/bpf
Define and initialize control file descriptors.
Signed-off-by: Alexey Budankov
---
tools/perf/util/evlist.c | 3 +++
tools/perf/util/evlist.h | 5 +
2 files changed, 8 insertions(+)
diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
index 2a9de6491700..0872b0b04a42 100644
Implement adding of file descriptors to fixed size (currently 1)
storage at struct fdarray by the dedicated fdarray__add_stat().
Append the static descriptors to the array used by poll() syscall
at fdarray__poll(). Copy poll() result of the descriptors from the
array back to the storage for
On 20.05.2020 15:38, Jiri Olsa wrote:
> On Wed, May 13, 2020 at 10:59:00AM +0300, Alexey Budankov wrote:
>>
>> Define and initialize control file descriptors.
>>
>> Signed-off-by: Alexey Budankov
>> ---
>> tools/perf/util/evlist.c | 3 +++
>>
On Wed, May 13, 2020 at 10:59:00AM +0300, Alexey Budankov wrote:
>
> Define and initialize control file descriptors.
>
> Signed-off-by: Alexey Budankov
> ---
> tools/perf/util/evlist.c | 3 +++
> tools/perf/util/evlist.h | 3 +++
> 2 files changed, 6 insertions(+)
>
Define and initialize control file descriptors.
Signed-off-by: Alexey Budankov
---
tools/perf/util/evlist.c | 3 +++
tools/perf/util/evlist.h | 3 +++
2 files changed, 6 insertions(+)
diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
index 2a9de6491700..aa61619fa304 100644
Define and initialize control file descriptors.
Signed-off-by: Alexey Budankov
---
tools/perf/util/evlist.c | 3 +++
tools/perf/util/evlist.h | 3 +++
2 files changed, 6 insertions(+)
diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
index 0a0b760d6948..2db4bedc4f81 100644
Define and initialize control file descriptors.
Signed-off-by: Alexey Budankov
---
tools/perf/util/evlist.c | 3 +++
tools/perf/util/evlist.h | 3 +++
2 files changed, 6 insertions(+)
diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
index 0a0b760d6948..2db4bedc4f81 100644
From: Andi Kleen
Closing a perf fd can also trigger an IPI to the target CPU.
Use the same affinity technique as we use for reading/enabling events
to closing to optimize the CPU transitions.
Before on a large test case with 94 CPUs:
% time seconds usecs/call callserrors syscall
--
From: Andi Kleen
Closing a perf fd can also trigger an IPI to the target CPU.
Use the same affinity technique as we use for reading/enabling events
to closing to optimize the CPU transitions.
Before on a large test case with 94 CPUs:
% time seconds usecs/call callserrors syscall
--
On 10/1/19 10:38 AM, Alex Williamson wrote:
On Mon, 30 Sep 2019 18:55:32 -0500 Shawn Anastasio
wrote:
This patch adds region file descriptors to VFIO, a simple file
descriptor type that allows read/write/mmap operations on a single
region of a VFIO device.
This feature is particularly useful
On Mon, 30 Sep 2019 18:55:32 -0500
Shawn Anastasio wrote:
> This patch adds region file descriptors to VFIO, a simple file descriptor type
> that allows read/write/mmap operations on a single region of a VFIO device.
>
> This feature is particularly useful for privileged applicati
This patch adds region file descriptors to VFIO, a simple file descriptor type
that allows read/write/mmap operations on a single region of a VFIO device.
This feature is particularly useful for privileged applications that use VFIO
and wish to share file descriptors with unprivileged
Introduce a new type of VFIO file descriptor that allows
memfd-style semantics for regions of a VFIO device.
Unlike VFIO device file descriptors, region file descriptors
are limited to a single region, and all offsets (read, etc.)
are relative to the start of the region.
This allows for finer
On Wed, Jun 12, 2019 at 06:36:48PM +0900, Tomasz Figa wrote:
> When the application calls VIDIOC_DQBUF with the DMABUF memory type, the
> v4l2_buffer structure (or v4l2_plane structures) are filled with DMA-buf
> file descriptors. However, the current documentation does not explain
> w
On Wed, Jun 12, 2019 at 6:36 PM Tomasz Figa wrote:
>
> When the application calls VIDIOC_DQBUF with the DMABUF memory type, the
> v4l2_buffer structure (or v4l2_plane structures) are filled with DMA-buf
> file descriptors. However, the current documentation does not explain
> wh
Hi,
On Wed, 2019-06-12 at 18:36 +0900, Tomasz Figa wrote:
> When the application calls VIDIOC_DQBUF with the DMABUF memory type, the
> v4l2_buffer structure (or v4l2_plane structures) are filled with DMA-buf
> file descriptors. However, the current documentation does not explain
> w
When the application calls VIDIOC_DQBUF with the DMABUF memory type, the
v4l2_buffer structure (or v4l2_plane structures) are filled with DMA-buf
file descriptors. However, the current documentation does not explain
whether those are new file descriptors referring to the same DMA-bufs or
just the
/man2/splice.2
+++ b/man2/splice.2
@@ -155,7 +155,9 @@ is set to indicate the error.
.B EAGAIN
.B SPLICE_F_NONBLOCK
was specified in
-.IR flags ,
+.IR flags
+or one of the file descriptors had been marked as nonblocking
+.RB ( O_NONBLOCK ) ,
and the operation would block.
.TP
.B EBADF
/tee.2
+++ b/man2/tee.2
@@ -100,7 +100,9 @@ is set to indicate the error.
.B EAGAIN
.B SPLICE_F_NONBLOCK
was specified in
-.IR flags ,
+.IR flags
+or one of the file descriptors had been marked as nonblocking
+.RB ( O_NONBLOCK ) ,
and the operation would block.
.TP
.B EINVAL
specified in
-.IR flags ,
+.IR flags
+or one of the file descriptors had been marked as nonblocking
+.RB ( O_NONBLOCK ) ,
and the operation would block.
.TP
.B EINVAL
--
2.19.1
SPLICE_F_NONBLOCK
was specified in
-.IR flags ,
+.IR flags
+or one of the file descriptors had been marked as nonblocking
+.RB ( O_NONBLOCK ) ,
and the operation would block.
.TP
.B EBADF
--
2.19.1
On 2018-11-19, Daniel Colascione wrote:
> > I wonder how fast it would be holding a pid with another open()ed fd.
> > And then you need to read comm (or how you filter whom to kill).
> > It seems to me that procfs will be even slower with this safe-way.
> > But I might misunderstand the idea, excu
On Mon, Nov 19, 2018 at 8:13 AM, Dmitry Safonov <0x7f454...@gmail.com> wrote:
> I wonder how fast it would be holding a pid with another open()ed fd.
> And then you need to read comm (or how you filter whom to kill).
> It seems to me that procfs will be even slower with this safe-way.
> But I might
Dmitry Safonov <0x7f454...@gmail.com> writes:
>
> So, I just wanted to gently remind about procfs with netlink socket[1].
> It seems to me that whenever you receive() pid information, you
> can request some uniq 64(?) bit number and kill the process using it.
> Whenever uniqueness of 64-bit number
On Sun, 18 Nov 2018 at 18:30, Andy Lutomirski wrote:
> Here's my point: if we're really going to make a new API to manipulate
> processes by their fd, I think we should have at least a decent idea
> of how that API will get extended in the future. Right now, we have
> an extremely awkward situati
On Sun, Nov 18, 2018 at 12:17:51PM +0100, Christian Brauner wrote:
> With this patch an open() call on /proc/ will give userspace a handle
> to struct pid of the process associated with /proc/. This allows to
> maintain a stable handle on a process.
> I have been discussing various approaches exten
1 - 100 of 271 matches
Mail list logo
