Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751965AbbG0LBF (ORCPT ); Mon, 27 Jul 2015 07:01:05 -0400 Received: from mail-wi0-f173.google.com ([209.85.212.173]:35572 "EHLO mail-wi0-f173.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750722AbbG0LBB (ORCPT ); Mon, 27 Jul 2015 07:01:01 -0400 Message-ID: <55B60F62.6010303@gmail.com> Date: Mon, 27 Jul 2015 13:00:50 +0200 From: "Michael Kerrisk (man-pages)" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Davidlohr Bueso , Peter Zijlstra CC: mtk.manpages@gmail.com, Thomas Gleixner , Darren Hart , "Carlos O'Donell" , Ingo Molnar , Jakub Jelinek , "linux-man@vger.kernel.org" , lkml , Arnd Bergmann , Steven Rostedt , Linux API , Torvald Riegel , Roland McGrath , Darren Hart , Anton Blanchard , Eric Dumazet , bill o gallmeister , Jan Kiszka , Daniel Wagner , Rich Felker , Andy Lutomirski , bert hubert , Rusty Russell , Heinrich Schuchardt Subject: Re: Revised futex(2) man page for review References: <55166C01.7000803@gmail.com> <20150328114725.GJ27490@worktop.programming.kicks-ass.net> <20150328120337.GB32047@worktop.ger.corp.intel.com> <1427834205.20009.19.camel@stgolabs.net> In-Reply-To: <1427834205.20009.19.camel@stgolabs.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2535 Lines: 57 Hi David, On 03/31/2015 10:36 PM, Davidlohr Bueso wrote: > On Sat, 2015-03-28 at 13:03 +0100, Peter Zijlstra wrote: >>> If the timeout argument is non-NULL, its contents specify a rel‐ >>> ative timeout for the wait, measured according to the >>> CLOCK_MONOTONIC clock. (This interval will be rounded up to the >>> system clock granularity, and kernel scheduling delays mean that >>> the blocking interval may overrun by a small amount.) If time‐ >>> out is NULL, the call blocks indefinitely. >> >> Would it not be better to only state that the wait will not return >> before the timeout -- unless woken -- and not bother with clock >> granularity and scheduling delays? > > Yeah, similarly we also have this: > > FUTEX_PRIVATE_FLAG (since Linux 2.6.22) > This option bit can be employed with all futex operations. It > tells the kernel that the futex is process-private and not > shared with another process (i.e., it is only being used for > synchronization between threads of the same process). This > allows the kernel to choose the fast path for validating the > user-space address and avoids expensive VMA lookups, taking ref‐ > erence counts on file backing store, and so on. > > This to me reads a bit too much into the kernel (fastpath, refcnt, > vmas). Why not just mention that it avoids overhead in the kernel or > something? I don't recall any manpage mentioning such details, but I > could be wrong. Thanks. Agreed. I changed this to This allows the kernel to make some additional performance optimizations. > In any case its a nit, the whole doc is pretty good and > I hope you can merge it soon and then just increment ;) I ran out of time and energy at a certain point. And also got a little disheartened that I got more people complaining about groff markup than actually looked looked at the FIXMEs in the page source :-). I'll try to reboot the process. Cheers, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ -- 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/