Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756696AbcDGQjG (ORCPT ); Thu, 7 Apr 2016 12:39:06 -0400 Received: from mail-io0-f193.google.com ([209.85.223.193]:34594 "EHLO mail-io0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755546AbcDGQjD (ORCPT ); Thu, 7 Apr 2016 12:39:03 -0400 MIME-Version: 1.0 In-Reply-To: <20160407111938.GR3430@twins.programming.kicks-ass.net> References: <1459789313-4917-1-git-send-email-mathieu.desnoyers@efficios.com> <1459789313-4917-2-git-send-email-mathieu.desnoyers@efficios.com> <5702A037.60200@zytor.com> <492303698.44994.1459799188052.JavaMail.zimbra@efficios.com> <856357054.45028.1459802903401.JavaMail.zimbra@efficios.com> <5703E191.2040707@redhat.com> <20160405164722.GB3430@twins.programming.kicks-ass.net> <570621E5.7060306@redhat.com> <20160407103158.GP3430@twins.programming.kicks-ass.net> <570638D9.7010108@redhat.com> <20160407111938.GR3430@twins.programming.kicks-ass.net> Date: Thu, 7 Apr 2016 09:39:02 -0700 X-Google-Sender-Auth: lSpSzYC83l7KFpNf3d8krjqabHI Message-ID: Subject: Re: [RFC PATCH v6 1/5] Thread-local ABI system call: cache CPU number of running thread From: Linus Torvalds To: Peter Zijlstra Cc: Florian Weimer , Mathieu Desnoyers , "H. Peter Anvin" , Andrew Morton , Russell King , Thomas Gleixner , Ingo Molnar , Linux Kernel Mailing List , linux-api , Paul Turner , Andrew Hunter , Andy Lutomirski , Andi Kleen , Dave Watson , Chris Lameter , Ben Maurer , rostedt , "Paul E. McKenney" , Josh Triplett , Catalin Marinas , Will Deacon , Michael Kerrisk , Boqun Feng 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-Length: 2467 Lines: 61 On Thu, Apr 7, 2016 at 4:19 AM, Peter Zijlstra wrote: > > People objected against the fixed size scheme, but it being possible to > get a fixed TCB offset and reduce indirections is a big win IMO. Guys, I'm going to just make an executive decision here, because this whole "fixed vs some strange size that is a superset of kernel and user mode knowledge" discussion has been going on for too long. Here's the executive decision: I will not merge anything that doesn't have a (small) fixed size as far as the kernel is concerned. Why? I don't think there is *any* possible reason for the kernel to care about the size. There will be no future extensions. The kernel will not magically start doing bigger things, and change more fields, or anything like that. Put another way: if the interface cannot be designed so that the kernel simply DOES NOT HAVE TO CARE about the rest of the crap, I will not merge this patch series. Ever. So I don't want to hear more idiotic emails about "extensible sizes". The people who want to push this interface had better be able to show that the kernel will never care about what user space does, and *all* the kernel has to do is to invalidate a single field when a thread is moved. In other words: - get rid of the stupid "abi features" bitfield. Anybody who feels it is needed had better take a deep breath and ask themselves why. - that leaves us with *one* single 32-bit field that the kernel cares about: "cpu_id". - we specify that the *only* thing the kernel will ever do is that single put_user(raw_smp_processor_id(), &t->tlabi->cpu_id) and absolutely nothing else. End result? That damn data structure is 32 bits. No more, no less. I'm perfectly happy to make a strict requiremnt that it is some 16-byte aligned thing, and we can add padding values, but quite frankly, I'm not really sure even that is required. And if the kernel ever has to care about anything else, I say "no". Can anybody give a *coherent* and actual *real* reason why the kernel would ever care about anything else? Because if not, then this discussion is done for. Stop with the f*cking idiotic "let's look at some kernel size and user-space size and try to match them up". The kernel doesn't care. The kernel MUST NOT care. The kernel will touch one single word, and that's all the kernel does, and user space had better be able make up their own semantics around that. Linus