From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751978AbdI1H1I (ORCPT ); Thu, 28 Sep 2017 03:27:08 -0400 Received: from mail-wm0-f68.google.com ([74.125.82.68]:49445 "EHLO mail-wm0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751474AbdI1H1G (ORCPT ); Thu, 28 Sep 2017 03:27:06 -0400 X-Google-Smtp-Source: AOwi7QBYo53T25NDbo4vsNCMbnyMXuksjsAZdz73wS63lNOIG5fpfLhwCfKIcJK3KDnxbQ7jN7ilsm9RF8xHyNB+n3s= MIME-Version: 1.0 Reply-To: mtk.manpages@gmail.com In-Reply-To: References: <20170924200620.GA24368@avx2> <9bc11ace-d111-cdef-5280-8cdda027ae9a@gmail.com> <20170926190018.GA30898@avx2> From: "Michael Kerrisk (man-pages)" Date: Thu, 28 Sep 2017 09:26:44 +0200 Message-ID: Subject: Re: [PATCH 1/2 v2] fdmap(2) To: Andy Lutomirski Cc: Alexey Dobriyan , Andrew Morton , "linux-kernel@vger.kernel.org" , Linux API , Randy Dunlap , Thomas Gleixner , Djalal Harouni , Alexey Gladkov , Aliaksandr Patseyenak , Tatsiana Brouka Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nfs id v8S7REQb029414 On 27 September 2017 at 17:03, Andy Lutomirski wrote: > On Tue, Sep 26, 2017 at 12:00 PM, Alexey Dobriyan wrote: >> On Mon, Sep 25, 2017 at 09:42:58AM +0200, Michael Kerrisk (man-pages) wrote: >>> [Not sure why original author is not in CC; added] >>> >>> Hello Alexey, >>> >>> On 09/24/2017 10:06 PM, Alexey Dobriyan wrote: >>> > From: Aliaksandr Patseyenak >>> > >>> > Implement system call for bulk retrieveing of opened descriptors >>> > in binary form. >>> > >>> > Some daemons could use it to reliably close file descriptors >>> > before starting. Currently they close everything upto some number >>> > which formally is not reliable. Other natural users are lsof(1) and CRIU >>> > (although lsof does so much in /proc that the effect is thoroughly buried). >>> > >>> > /proc, the only way to learn anything about file descriptors may not be >>> > available. There is unavoidable overhead associated with instantiating >>> > 3 dentries and 3 inodes and converting integers to strings and back. >>> > >>> > Benchmark: >>> > >>> > N=1<<22 times >>> > 4 opened descriptors (0, 1, 2, 3) >>> > opendir+readdir+closedir /proc/self/fd vs fdmap >>> > >>> > /proc 8.31 ą 0.37% >>> > fdmap 0.32 ą 0.72% >>> >>> From the text above, I'm still trying to understand: whose problem >>> does this solve? I mean, we've lived with the daemon-close-all-files >>> technique forever (and I'm not sure that performance is really an >>> important issue for the daemon case) . >> >>> And you say that the effect for lsof(1) will be buried. >> >> If only fdmap(2) is added, then effect will be negligible for lsof >> because it has to go through /proc anyway. >> >> The idea is to start process. In ideal world, only bynary system calls >> would exist and shells could emulate /proc/* same way bash implement >> /dev/tcp > > Then start the process by doing it for real and making it obviously > useful. We should not add a pair of vaguely useful, rather weak > syscalls just to start a process of modernizing /proc. I concur. Alexey, you still have not wxplained who specifically needs this right now, and how, precisely, they plan to use the new system calls. It is all very arm-wavey so far. Thanks, Michael