Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932354AbbGGQ4o (ORCPT ); Tue, 7 Jul 2015 12:56:44 -0400 Received: from mail-ig0-f173.google.com ([209.85.213.173]:37130 "EHLO mail-ig0-f173.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757386AbbGGQ4g (ORCPT ); Tue, 7 Jul 2015 12:56:36 -0400 Message-ID: <559C04C2.8090508@gmail.com> Date: Tue, 07 Jul 2015 10:56:34 -0600 From: David Ahern User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Andy Lutomirski , Arnaldo Carvalho de Melo CC: Andrew Vagin , Andrey Vagin , "linux-kernel@vger.kernel.org" , Linux API , Oleg Nesterov , Andrew Morton , Cyrill Gorcunov , Pavel Emelyanov , Roger Luethi , Arnd Bergmann , Pavel Odintsov Subject: Re: [PATCH 0/24] kernel: add a netlink interface to get information about processes (v2) References: <1436172445-6979-1-git-send-email-avagin@openvz.org> <20150707154345.GA1593@odin.com> <20150707162552.GM3326@kernel.org> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2353 Lines: 48 On 7/7/15 10:27 AM, Andy Lutomirski wrote: > On Tue, Jul 7, 2015 at 9:25 AM, Arnaldo Carvalho de Melo > 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 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/