Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1031285AbbDWXE6 (ORCPT ); Thu, 23 Apr 2015 19:04:58 -0400 Received: from mail-ig0-f177.google.com ([209.85.213.177]:34873 "EHLO mail-ig0-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1031239AbbDWXEw (ORCPT ); Thu, 23 Apr 2015 19:04:52 -0400 MIME-Version: 1.0 In-Reply-To: References: <1429792491-5978-1-git-send-email-dvlasenk@redhat.com> <20150423211015.GS28327@pd.tnic> <55396617.4020303@zytor.com> <553972D5.2070104@zytor.com> <553977AA.9040802@zytor.com> Date: Thu, 23 Apr 2015 16:04:50 -0700 X-Google-Sender-Auth: SSEGcpGPSmySXBv5Tr0wsEUkVfk Message-ID: Subject: Re: [PATCH] x86/asm/entry/32: Restore %ss before SYSRETL if necessary From: Linus Torvalds To: Andy Lutomirski Cc: "H. Peter Anvin" , Borislav Petkov , Denys Vlasenko , Brian Gerst , Denys Vlasenko , Ingo Molnar , Steven Rostedt , Oleg Nesterov , Frederic Weisbecker , Alexei Starovoitov , Will Drewry , Kees Cook , "the arch/x86 maintainers" , Linux Kernel Mailing List 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: 1454 Lines: 29 On Thu, Apr 23, 2015 at 3:55 PM, Andy Lutomirski wrote: > > It's a matter of the ratio, right? One cycle of syscall overhead > saved is worth some number of context switch cycles added, and the > ratio probably varies by workload. Yeah. That said, I do think Peter is right that there are usually a *lot* more system calls than there are context switches, even if I guess you could come up with specific cases where that isn't true (eg in-kernel file servers etc that never actually go to user space). And the scheduler approach would have the benefit of not being in asm code, so we can more easily use things like static keys or alternative_asm() to make the overhead go away on CPU's that don't need it. We certainly _can_ do that in an *.S file too, but we don't have quite the same level of infrastructure help to do it. Adding some static key protected thing to switch_to() in arch/x86/kernel/process_64.c wouldn't seem too bad. And at that point, the only cost is a a single no-op on most CPU's (we still don't know _which_ AMD CPU's are affected, but I guess we could start off with all of them and see if we can get an exhaustive list some way). Linus -- 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/