From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qc0-f176.google.com (mail-qc0-f176.google.com [209.85.216.176]) by kanga.kvack.org (Postfix) with ESMTP id D7AD06B0035 for ; Tue, 11 Feb 2014 13:43:39 -0500 (EST) Received: by mail-qc0-f176.google.com with SMTP id e16so13499973qcx.21 for ; Tue, 11 Feb 2014 10:43:39 -0800 (PST) Received: from qmta14.emeryville.ca.mail.comcast.net (qmta14.emeryville.ca.mail.comcast.net. [2001:558:fe2d:44:76:96:27:212]) by mx.google.com with ESMTP id s22si13135343qge.16.2014.02.11.10.43.38 for ; Tue, 11 Feb 2014 10:43:38 -0800 (PST) Date: Tue, 11 Feb 2014 12:43:35 -0600 (CST) From: Christoph Lameter Subject: Re: Memory allocator semantics In-Reply-To: Message-ID: References: <20140102203320.GA27615@linux.vnet.ibm.com> <52F60699.8010204@iki.fi> <20140209020004.GY4250@linux.vnet.ibm.com> Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mm@kvack.org List-ID: To: Pekka Enberg Cc: Paul McKenney , "linux-mm@kvack.org" , LKML , Matt Mackall On Tue, 11 Feb 2014, Pekka Enberg wrote: > So again, there's nothing in (A) that the memory allocator is > concerned about. kmalloc() makes no guarantees whatsoever about the > visibility of "r1" across CPUs. If you're saying that there's an > implicit barrier between kmalloc() and kfree(), that's an unintended > side-effect, not a design decision AFAICT. I am not sure that this side effect necessarily happens. The SLUB fastpath does not disable interrupts and only uses a cmpxchg without lock semantics. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org