Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757829AbbGGQRs (ORCPT ); Tue, 7 Jul 2015 12:17:48 -0400 Received: from mail-ie0-f169.google.com ([209.85.223.169]:33702 "EHLO mail-ie0-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753112AbbGGQRi (ORCPT ); Tue, 7 Jul 2015 12:17:38 -0400 Message-ID: <559BFB9C.5010801@gmail.com> Date: Tue, 07 Jul 2015 10:17:32 -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 , Andrew Vagin CC: Andrey Vagin , "linux-kernel@vger.kernel.org" , Linux API , Oleg Nesterov , Andrew Morton , Cyrill Gorcunov , Pavel Emelyanov , Roger Luethi , Arnd Bergmann , Arnaldo Carvalho de Melo , 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> 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: 1345 Lines: 28 On 7/7/15 9:56 AM, Andy Lutomirski wrote: > Netlink is fine for these use cases (if they were related to the > netns, not the pid ns or user ns), and it works. It's still tedious > -- I bet that if you used a syscall, the user code would be > considerable shorter, though. :) > > How would this be a problem if you used plain syscalls? The user > would make a request, and the syscall would tell the user that their > result buffer was too small if it was, in fact, too small. It will be impossible to tell a user what sized buffer is needed. The size is largely a function of the number of tasks and number of maps per thread group and both of those will be changing. With the growing size of systems (I was sparc systems with 1024 cpus) the workload can be 10's of thousands of tasks each with a lot of maps (e.g., java workloads). That amounts to a non-trivial amount of data that has to be pushed to userspace. One of the benefits of the netlink approach is breaking the data across multiple messages and picking up where you left off. That infrastructure is already in place. David -- 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/