From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter Zijlstra Subject: Re: [patch 00/41] cpu alloc / cpu ops v3: Optimize per cpu access Date: Fri, 30 May 2008 21:13:18 +0200 Message-ID: <1212174798.24826.44.camel@lappy.programming.kicks-ass.net> References: <20080530035620.587204923@sgi.com> <1212138752.12349.227.camel@twins> <20080530091847.GA26563@elte.hu> <1212172834.24826.22.camel@lappy.programming.kicks-ass.net> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Return-path: Received: from bombadil.infradead.org ([18.85.46.34]:49987 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752221AbYE3TOI (ORCPT ); Fri, 30 May 2008 15:14:08 -0400 In-Reply-To: Sender: linux-arch-owner@vger.kernel.org List-ID: To: Christoph Lameter Cc: Ingo Molnar , akpm@linux-foundation.org, linux-arch@vger.kernel.org, Thomas Gleixner , Steven Rostedt On Fri, 2008-05-30 at 11:56 -0700, Christoph Lameter wrote: > On Fri, 30 May 2008, Peter Zijlstra wrote: > > > Yes, I get that, but for instance kmem_cache_cpu usage would require > > horrible long preempt off sections, hence we add a lock and manage > > consistency using that lock instead of strict per-cpu and preempt > > disable. > > Really? Where is that horrible long preempt off section? I thought they > were all short and we use semaphores when looping over all slabs. Remember, horribly long on -rt is in the order of ~30us. See for instance the path: flush_slab() slab_lock() <-- bit_spinlock deactive_slab() loop over objects unfreeze_slab() add_partial() spin_lock(&n->list_lock) <-- another lock all of that runs with preempt disabled, and worse it can spin for some indefinite amount of time. That is totally unacceptable on -rt, so we need to make it all preemptible and use sleeping locks (IRQ inversion can't happen, for the only thing that runs in hardirq is try_to_wake_up()).