From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756340Ab2FJK13 (ORCPT ); Sun, 10 Jun 2012 06:27:29 -0400 Received: from mail-ob0-f174.google.com ([209.85.214.174]:44117 "EHLO mail-ob0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754754Ab2FJK11 (ORCPT ); Sun, 10 Jun 2012 06:27:27 -0400 MIME-Version: 1.0 In-Reply-To: References: <1339176197-13270-1-git-send-email-js1304@gmail.com> <1339176197-13270-4-git-send-email-js1304@gmail.com> Date: Sun, 10 Jun 2012 19:27:27 +0900 Message-ID: Subject: Re: [PATCH 4/4] slub: deactivate freelist of kmem_cache_cpu all at once in deactivate_slab() From: JoonSoo Kim To: Christoph Lameter Cc: Pekka Enberg , linux-kernel@vger.kernel.org, linux-mm@kvack.org Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 2012/6/9 Christoph Lameter : > On Sat, 9 Jun 2012, Joonsoo Kim wrote: > >> Current implementation of deactivate_slab() which deactivate >> freelist of kmem_cache_cpu one by one is inefficient. >> This patch changes it to deactivate freelist all at once. >> But, there is no overall performance benefit, >> because deactivate_slab() is invoked infrequently. > > Hmm, deactivate freelist can race with slab_free. Need to look at this in > detail. Implemented logic is nearly same as previous one. I just merge first step of previous deactivate_slab() with second one. In case of failure of cmpxchg_double_slab(), reloading page->freelist, page->counters and recomputing inuse ensure that race with slab_free() cannot be possible. In case that we need a lock, try to get a lock before invoking cmpxchg_double_slab(), so race with slab_free cannot be occured too. Above is my humble opinion, please give me some comments. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx165.postini.com [74.125.245.165]) by kanga.kvack.org (Postfix) with SMTP id 171636B005C for ; Sun, 10 Jun 2012 06:27:28 -0400 (EDT) Received: by obbwd18 with SMTP id wd18so6680299obb.14 for ; Sun, 10 Jun 2012 03:27:27 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: <1339176197-13270-1-git-send-email-js1304@gmail.com> <1339176197-13270-4-git-send-email-js1304@gmail.com> Date: Sun, 10 Jun 2012 19:27:27 +0900 Message-ID: Subject: Re: [PATCH 4/4] slub: deactivate freelist of kmem_cache_cpu all at once in deactivate_slab() From: JoonSoo Kim Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-linux-mm@kvack.org List-ID: To: Christoph Lameter Cc: Pekka Enberg , linux-kernel@vger.kernel.org, linux-mm@kvack.org 2012/6/9 Christoph Lameter : > On Sat, 9 Jun 2012, Joonsoo Kim wrote: > >> Current implementation of deactivate_slab() which deactivate >> freelist of kmem_cache_cpu one by one is inefficient. >> This patch changes it to deactivate freelist all at once. >> But, there is no overall performance benefit, >> because deactivate_slab() is invoked infrequently. > > Hmm, deactivate freelist can race with slab_free. Need to look at this in > detail. Implemented logic is nearly same as previous one. I just merge first step of previous deactivate_slab() with second one. In case of failure of cmpxchg_double_slab(), reloading page->freelist, page->counters and recomputing inuse ensure that race with slab_free() cannot be possible. In case that we need a lock, try to get a lock before invoking cmpxchg_double_slab(), so race with slab_free cannot be occured too. Above is my humble opinion, please give me some comments. -- 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