From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2992802AbXDYQV6 (ORCPT ); Wed, 25 Apr 2007 12:21:58 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S2992823AbXDYQV6 (ORCPT ); Wed, 25 Apr 2007 12:21:58 -0400 Received: from netops-testserver-4-out.sgi.com ([192.48.171.29]:53417 "EHLO relay.sgi.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S2992802AbXDYQV5 (ORCPT ); Wed, 25 Apr 2007 12:21:57 -0400 Date: Wed, 25 Apr 2007 09:21:56 -0700 (PDT) From: Christoph Lameter X-X-Sender: clameter@schroedinger.engr.sgi.com To: Hugh Dickins cc: Andrew Morton , linux-kernel@vger.kernel.org Subject: Re: [PATCH -mm] slub: update cpu after new_slab() In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 25 Apr 2007, Hugh Dickins wrote: > But, surely you wouldn't have expected it to stay on the processor > throughout the waiting page allocation?? I think you're misremembering > your expectations, and this was just a simple, understandable, oversight. You do not know my fuzzy brain... Some thoughts go wrong once and twice and then are stuck in there and I need people like you to straighten me out. > Quite a serious one, though: it got caught in my case by the NULL > dereference, but it's probably been switching cpu there much more > often - one cpu diddling with what's private to another, with > unpredictable results. Right. Thanks for catching it.