lkml.org 
[lkml]   [2015]   [Jul]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 0/24] kernel: add a netlink interface to get information about processes (v2)
On 7/7/15 10:27 AM, Andy Lutomirski wrote:
> On Tue, Jul 7, 2015 at 9:25 AM, Arnaldo Carvalho de Melo
> <acme@kernel.org> wrote:
>> Em Tue, Jul 07, 2015 at 06:43:46PM +0300, Andrew Vagin escreveu:
>>> On Mon, Jul 06, 2015 at 10:10:32AM -0700, Andy Lutomirski wrote:
>>>> On Mon, Jul 6, 2015 at 1:47 AM, Andrey Vagin <avagin@openvz.org> wrote:
>>>> Would it make more sense to have a new syscall instead? You could
>>>> even still use nlattr formatting for the syscall results.
>>>
>>> Andy, thank you for the feedback. I got your points. I need time to
>>> think about them. I suppose that a new syscall can be more suitable in
>>> this case, and I need time to form a vision of it. If you have any ideas
>>> or thoughts, I would be glad to know about them.
>>
>> If a new syscall would indeed be better for this, then using
>> sys_perf_event_open and on one of the perf_event_attr flip a bit to ask
>> for those PERF_RECORD_{COMM,FORK,PERF_RECORD_MMAP2, etc} to be generated
>> in the perf buffer could make it reuse all the userspace tooling, with
>> really minimal change: flip the bit, don't synthesize it from /proc.
>>
>
> Hmm, that's an interesting thought.
>
> Andrew, would that work for you?

It's an interesting option to look at. It provides a fixed sized ring
buffer. The dummy event can be used as the event to trigger the
generation of task data. The LOST event can tell you if the buffer is
too small.

Of course the devil is in the details. The buffer for event tasks will
need to be fairly large. That size is only needed for the initial task
data meaning the global mmap size is not right for it and this
particular buffer can be reduced after startup.

The initial task detection can generate a flood of data in a very short
amount of time since kernel side is in a tight loop walking tasks and
maps and there is nothing to throttle it beyond the buffer filling --
and that just means lost data -- and an occasional need_resched check.
Perhaps the kernel loop will need to pause if the buffer is full to give
userspace a moment to collect data rather than just dropping it.




\
 
 \ /
  Last update: 2015-07-07 19:21    [W:0.207 / U:0.220 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site