Re: [PATCH 0/24] kernel: add a netlink interface to get information about processes (v2)

[David Ahern]

On 7/7/15 10:27 AM, Andy Lutomirski wrote:
> On Tue, Jul 7, 2015 at 9:25 AM, Arnaldo Carvalho de Melo
> <acme@xxxxxxxxxx> 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@xxxxxxxxxx> 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.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/