From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753578Ab3HLR6i (ORCPT ); Mon, 12 Aug 2013 13:58:38 -0400 Received: from mail-ee0-f44.google.com ([74.125.83.44]:48547 "EHLO mail-ee0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752298Ab3HLR6e (ORCPT ); Mon, 12 Aug 2013 13:58:34 -0400 Date: Mon, 12 Aug 2013 19:58:30 +0200 From: Ingo Molnar To: Linus Torvalds Cc: Peter Zijlstra , Thomas Gleixner , Mike Galbraith , Peter Anvin , Andi Kleen , Linux Kernel Mailing List Subject: Re: [RFC] per-cpu preempt_count Message-ID: <20130812175830.GB18691@gmail.com> References: <20130812115113.GE27162@twins.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Linus Torvalds wrote: > On Mon, Aug 12, 2013 at 4:51 AM, Peter Zijlstra wrote: > > > > The below boots to wanting to mount a root filesystem with > > CONFIG_PREEMPT=y using kvm -smp 4. > > But doesn't work in general? Or you just never tested? (I think Peter never tested it on real hw - this is an RFC patch to show the concept .) > > Adding TIF_NEED_RESCHED into the preempt count would allow a single > > test in preempt_check_resched() instead of still needing the TI. > > Removing PREEMPT_ACTIVE from preempt count should allow us to get rid > > of ti::preempt_count altogether. > > > > The only problem with TIF_NEED_RESCHED is that its cross-cpu which > > would make the entire thing atomic which would suck donkey balls so > > maybe we need two separate per-cpu variables? > > Agreed. Making it atomic would suck, and cancel all advantages of the > better code generation to access it. Good point. We could still have the advantages of NEED_RESCHED in preempt_count() by realizing that we only rarely actually set/clear need_resched and mostly read it from the highest freq user, the preempt_enable() check. So we could have it atomic, but do atomic_read() in the preempt_enable() hotpath which wouldn't suck donkey balls, right? That would allow a really sweet preempt_enable() fastpath, on x86 at least. Thanks, Ingo