From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1754009AbbFRKki (ORCPT <rfc822;w@1wt.eu>);
	Thu, 18 Jun 2015 06:40:38 -0400
Received: from bombadil.infradead.org ([198.137.202.9]:55611 "EHLO
	bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1753310AbbFRKkb (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Thu, 18 Jun 2015 06:40:31 -0400
Date: Thu, 18 Jun 2015 12:40:15 +0200
From: Peter Zijlstra <peterz@infradead.org>
To: Ingo Molnar <mingo@kernel.org>
Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>, umgwanakikbuti@gmail.com,
        mingo@elte.hu, ktkhai@parallels.com, rostedt@goodmis.org,
        tglx@linutronix.de, juri.lelli@gmail.com, pang.xunlei@linaro.org,
        oleg@redhat.com, wanpeng.li@linux.intel.com,
        linux-kernel@vger.kernel.org, Al Viro <viro@ZenIV.linux.org.uk>,
        Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [PATCH 11/18] seqcount: Introduce raw_write_seqcount_barrier()
Message-ID: <20150618104015.GL19282@twins.programming.kicks-ass.net>
References: <20150611153341.GK3913@linux.vnet.ibm.com>
 <20150611214557.GA4249@linux.vnet.ibm.com>
 <20150617122924.GP3644@twins.programming.kicks-ass.net>
 <20150617145712.GZ3913@linux.vnet.ibm.com>
 <20150617154926.GE19282@twins.programming.kicks-ass.net>
 <20150617163731.GD3913@linux.vnet.ibm.com>
 <20150617171140.GG19282@twins.programming.kicks-ass.net>
 <20150617180214.GJ3913@linux.vnet.ibm.com>
 <20150618091505.GI19282@twins.programming.kicks-ass.net>
 <20150618094014.GC1094@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20150618094014.GC1094@gmail.com>
User-Agent: Mutt/1.5.21 (2012-12-30)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Thu, Jun 18, 2015 at 11:40:14AM +0200, Ingo Molnar wrote:

> In what retarded use-case do unasked for speculative writes even make any sense 
> beyond as a sadistic tool to make parallel, threaded code even more fragile??

So what worries me most is the "Takeaways" from the document:

  http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4455.html

Those read like a 'fuck you' to 30 years of concurrent code in C.

Sure, its nice and all that they finally have something that's
standardized, and this might be an option for new projects (in reality
it might only really be an option in another 5-10 years).

But the active encouragement to break existing code is utterly fucked.