From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/9596 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.kernel,gmane.linux.lib.musl.general Subject: Re: [musl] Re: [RFC PATCH] x86/vdso/32: Add AT_SYSINFO cancellation helpers Date: Sat, 12 Mar 2016 14:08:59 -0500 Message-ID: <20160312190859.GF9349@brightrain.aerifal.cx> References: <20160310111646.GA13102@gmail.com> <20160310164104.GM9349@brightrain.aerifal.cx> <20160310180331.GB15940@gmail.com> <20160310232819.GR9349@brightrain.aerifal.cx> <20160311093347.GA17749@gmail.com> <20160311113914.GD29662@port70.net> <20160312170040.GA1108@gmail.com> <20160312180531.GD9349@brightrain.aerifal.cx> <20160312184836.GA17707@gmail.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1457809769 9519 80.91.229.3 (12 Mar 2016 19:09:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 12 Mar 2016 19:09:29 +0000 (UTC) Cc: Linus Torvalds , Andy Lutomirski , the arch/x86 maintainers , Linux Kernel Mailing List , Borislav Petkov , "musl@lists.openwall.com" , Andrew Morton , Thomas Gleixner , Peter Zijlstra To: Ingo Molnar Original-X-From: linux-kernel-owner@vger.kernel.org Sat Mar 12 20:09:27 2016 Return-path: Envelope-to: glk-linux-kernel-3@plane.gmane.org Original-Received: from vger.kernel.org ([209.132.180.67]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aeoug-0001NR-0K for glk-linux-kernel-3@plane.gmane.org; Sat, 12 Mar 2016 20:09:22 +0100 Original-Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753368AbcCLTJN (ORCPT ); Sat, 12 Mar 2016 14:09:13 -0500 Original-Received: from 216-12-86-13.cv.mvl.ntelos.net ([216.12.86.13]:51729 "EHLO brightrain.aerifal.cx" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752167AbcCLTJH (ORCPT ); Sat, 12 Mar 2016 14:09:07 -0500 Original-Received: from dalias by brightrain.aerifal.cx with local (Exim 3.15 #2) id 1aeouJ-0006fI-00; Sat, 12 Mar 2016 19:08:59 +0000 Content-Disposition: inline In-Reply-To: <20160312184836.GA17707@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Xref: news.gmane.org gmane.linux.kernel:2175568 gmane.linux.lib.musl.general:9596 Archived-At: On Sat, Mar 12, 2016 at 07:48:36PM +0100, Ingo Molnar wrote: > > * Rich Felker wrote: > > > On Sat, Mar 12, 2016 at 06:00:40PM +0100, Ingo Molnar wrote: > > > > > > * Linus Torvalds wrote: > > > > > > > [...] > > > > > > > > Because if that's the case, I wonder if what you really want is not "sticky > > > > signals" as much as "synchronous signals" - ie the ability to say that a signal > > > > shouldn't ever interrupt in random places, but only at well-defined points > > > > (where a system call would be one such point - are there others?) > > > > > > Yes, I had similar 'deferred signal delivery' thoughts after having written up the > > > sticky signals approach, I just couldn't map all details of the semantics: see the > > > 'internal libc functions' problem below. > > > > > > If we can do this approach then there's another advantage as well: this way the C > > > library does not even have to poll for cancellation at syscall boundaries: i.e. > > > the regular system call fast path gets faster by 2-3 instructions as well. > > > > That is not a measurable benefit. You're talking about 2-3 cycles out of 10k or > > more cycles (these are heavy blocking syscalls not light things like SYS_time or > > SYS_getpid). > > Huh? The list of 'must be' cancellable system calls includes key system calls > like: > > open() > close() > read() variants > write() variants > poll() > select() > > which can be and often are very lightweight. The list of 'may be cancellable' > system calls includes even more lightweight system calls. > > I think you are confusing 'might block' with 'will block'. Most IO operations on a > modern kernel with modern hardware will not block! No, I just mean syscalls that may block are generally heavy operations. There may be a few exceptions (especially close in the case where it's not the last fd for an open file) but I think you'd be hard pressed to find a case where 2-3 cycles is even 0.2% of the syscall time. But my point was not to get derailed on an argument about the exact performance (non-)benefits of "saving 2-3 cycles", just to say this is not an interesting argument for one approach vs another and that it's a distraction from other much-more-important issues. > You are scaring me ... :-( I'm not sure how to interpret this, but if you really feel what I'm writing is scary/hostile I'll try to convey my ideas differently. Rich