Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1030645Ab3HJQnf (ORCPT ); Sat, 10 Aug 2013 12:43:35 -0400 Received: from mail-vb0-f53.google.com ([209.85.212.53]:57887 "EHLO mail-vb0-f53.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S966547Ab3HJQne (ORCPT ); Sat, 10 Aug 2013 12:43:34 -0400 MIME-Version: 1.0 In-Reply-To: <5206659F.9070705@zytor.com> References: <1376089460-5459-1-git-send-email-andi@firstfloor.org> <5205C4BB.6020003@zytor.com> <1376114128.5332.17.camel@marge.simpson.net> <5206659F.9070705@zytor.com> Date: Sat, 10 Aug 2013 09:43:33 -0700 X-Google-Sender-Auth: E49ZWK0rk5GuNk2iUriBIb8Lh3I Message-ID: Subject: Re: Re-tune x86 uaccess code for PREEMPT_VOLUNTARY From: Linus Torvalds To: "H. Peter Anvin" Cc: Mike Galbraith , Andi Kleen , Linux Kernel Mailing List , "the arch/x86 maintainers" , Ingo Molnar 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: 1767 Lines: 38 On Sat, Aug 10, 2013 at 9:09 AM, H. Peter Anvin wrote: > > Do you have any quantification of "munches throughput?" It seems odd > that it would be worse than polling for preempt all over the kernel, but > perhaps the additional locking is what costs. Actually, the big thing for true preemption is not so much the preempt count itself, but the fact that when the preempt count goes back to zero we have that "check if we should have been preempted" thing. And in particular, the conditional function call that goes along with it. The thing is, even if that is almost never taken, just the fact that there is a conditional function call very often makes code generation *much* worse. A function that is a leaf function with no stack frame with no preemption often turns into a non-leaf function with stack frames when you enable preemption, just because it had a RCU read region which disabled preemption. It's similar to the kind of code generation issue that Andi's patches are trying to work on. Andi did the "test and jump to a different section to call the scheduler with registers saved" as an assembly stub in one of his patches in this series exactly to avoid the cost of this for the might_sleep() case, and generated that GET_THREAD_AND_SCHEDULE asm macro for it. But look at that asm macro, and compare it to "preempt_check_resched()".. I have often wanted to have access to that kind of thing from C code. It's not unusual. Think lock failure paths, not Tom Jones. 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/