From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932297AbbAFDD2 (ORCPT ); Mon, 5 Jan 2015 22:03:28 -0500 Received: from smtp2.provo.novell.com ([137.65.250.81]:42594 "EHLO smtp2.provo.novell.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753388AbbAFDD0 (ORCPT ); Mon, 5 Jan 2015 22:03:26 -0500 Message-ID: <1420513392.24290.2.camel@stgolabs.net> Subject: Re: [PATCH 1/2] mm/slub: optimize alloc/free fastpath by removing preemption on/off From: Davidlohr Bueso To: Joonsoo Kim Cc: Andrew Morton , Christoph Lameter , Pekka Enberg , David Rientjes , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Jesper Dangaard Brouer , rostedt@goodmis.org, Thomas Gleixner Date: Mon, 05 Jan 2015 19:03:12 -0800 In-Reply-To: <1420421765-3209-1-git-send-email-iamjoonsoo.kim@lge.com> References: <1420421765-3209-1-git-send-email-iamjoonsoo.kim@lge.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.12.7 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 2015-01-05 at 10:36 +0900, Joonsoo Kim wrote: > - preempt_disable(); > - c = this_cpu_ptr(s->cpu_slab); > + do { > + tid = this_cpu_read(s->cpu_slab->tid); > + c = this_cpu_ptr(s->cpu_slab); > + } while (IS_ENABLED(CONFIG_PREEMPT) && unlikely(tid != c->tid)); > + barrier(); I don't see the compiler reodering the object/page stores below, since c is updated in the loop anyway. Is this really necessary (same goes for slab_free)? The generated code by gcc 4.8 looks correct without it. Additionally, the implied barriers for preemption control aren't really the same semantics used here (if that is actually the reason why you are using them). Thanks, Davidlohr