From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/9595 Path: news.gmane.org!not-for-mail From: Ingo Molnar Newsgroups: gmane.linux.lib.musl.general,gmane.linux.kernel Subject: Re: Re: [RFC PATCH] x86/vdso/32: Add AT_SYSINFO cancellation helpers Date: Sat, 12 Mar 2016 19:48:36 +0100 Message-ID: <20160312184836.GA17707@gmail.com> References: <20160310033446.GL9349@brightrain.aerifal.cx> <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> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1457808541 23751 80.91.229.3 (12 Mar 2016 18:49:01 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 12 Mar 2016 18:49:01 +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: Rich Felker Original-X-From: musl-return-9608-gllmg-musl=m.gmane.org@lists.openwall.com Sat Mar 12 19:48:55 2016 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1aeoaq-0001kA-UZ for gllmg-musl@m.gmane.org; Sat, 12 Mar 2016 19:48:53 +0100 Original-Received: (qmail 10011 invoked by uid 550); 12 Mar 2016 18:48:51 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 9992 invoked from network); 12 Mar 2016 18:48:50 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=TocaK044qEGlQU6AqsojY32E5yed6pPc8bPyoNfgH3I=; b=GTeF4yCkn9HXGkEg563/gdrBWXhqJvWu7Lt9EN4QgthcT7+OR0PsGhkWBqazXQZMnC Pr5NL5L6mJujh57pQb7ZYQq3FzilyWdRmnd20eUUGCPEyYaS592XkkrfL8aCdT3Ahmih B8jZs5x3sIq29yqzS692r1U/OSpbR120xJRxkvArumSAN1Q74Lytac/9jo3xPKQ4bek9 LsSwScWvu2BSo6QOt5sJR14fUQ6tTxWiJCqZPPPAQA0FMG6acrtmCKiU48xtsAezLGjx hZhOZ4AgT6/rLuNee1MZY7AJ8I3MYcACzNFqAWrJk/o7m7BbRg20gzIBAKU0CcHo3dIh DN9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to:user-agent; bh=TocaK044qEGlQU6AqsojY32E5yed6pPc8bPyoNfgH3I=; b=hIUe4hY+26gpPb6jqi2zWEpAQ/lHvbbhN6+f0kVgNinA1K6+XhpLhwjaYktDvXCvHG 37B78emq7sHbSBGdtUHBhZksUqc03KwlmhgZ7ygyo98UlLey6ojH3bm7oI2yz5rmQNZp SaQVia9WX8CJuvHthZqAGrAEKg68P4Rcf0LqVMmpLsxqmP2JHO9IIZlj1iz6CUV6ByGr f8gBhk/dshBi92V8MnoEx3B5O5NeK4X8vz7kUibBHn++TECB2O3I80PPiOzgLVRI5aO/ O8LC0B8K4C6WSfd96qTnObd5grDQ2I+svlvCqdpAxzM32zIWs96pRWoNifQmQDXVQa4p jW+Q== X-Gm-Message-State: AD7BkJKeuA9BhDPY1u3azqZeRMqGLvVj2HEYERAnv7V+NIjUcLS77g4Blb1GxZJCVCqsHw== X-Received: by 10.28.141.141 with SMTP id p135mr9319788wmd.30.1457808519488; Sat, 12 Mar 2016 10:48:39 -0800 (PST) Original-Sender: Ingo Molnar Content-Disposition: inline In-Reply-To: <20160312180531.GD9349@brightrain.aerifal.cx> User-Agent: Mutt/1.5.23 (2014-03-12) Xref: news.gmane.org gmane.linux.lib.musl.general:9595 gmane.linux.kernel:2175562 Archived-At: * 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! You are scaring me ... :-( Thanks, Ingo