From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754508AbXENNhJ (ORCPT ); Mon, 14 May 2007 09:37:09 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754873AbXENNgz (ORCPT ); Mon, 14 May 2007 09:36:55 -0400 Received: from viefep13-int.chello.at ([213.46.255.15]:29577 "EHLO viefep33-int.chello.at" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751006AbXENNgy (ORCPT ); Mon, 14 May 2007 09:36:54 -0400 Message-Id: <20070514131904.440041502@chello.nl> User-Agent: quilt/0.45-1 Date: Mon, 14 May 2007 15:19:04 +0200 From: Peter Zijlstra To: linux-kernel@vger.kernel.org, linux-mm@kvack.org Cc: Peter Zijlstra , Thomas Graf , David Miller , Andrew Morton , Daniel Phillips , Pekka Enberg , Christoph Lameter , Matt Mackall Subject: [PATCH 0/5] make slab gfp fair Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org In the interest of creating a reserve based allocator; we need to make the slab allocator (*sigh*, all three) fair with respect to GFP flags. That is, we need to protect memory from being used by easier gfp flags than it was allocated with. If our reserve is placed below GFP_ATOMIC, we do not want a GFP_KERNEL allocation to walk away with it - a scenario that is perfectly possible with the current allocators. From mboxrd@z Thu Jan 1 00:00:00 1970 Message-Id: <20070514131904.440041502@chello.nl> Date: Mon, 14 May 2007 15:19:04 +0200 From: Peter Zijlstra Subject: [PATCH 0/5] make slab gfp fair Sender: owner-linux-mm@kvack.org Return-Path: To: linux-kernel@vger.kernel.org, linux-mm@kvack.org Cc: Peter Zijlstra , Thomas Graf , David Miller , Andrew Morton , Daniel Phillips , Pekka Enberg , Christoph Lameter , Matt Mackall List-ID: In the interest of creating a reserve based allocator; we need to make the slab allocator (*sigh*, all three) fair with respect to GFP flags. That is, we need to protect memory from being used by easier gfp flags than it was allocated with. If our reserve is placed below GFP_ATOMIC, we do not want a GFP_KERNEL allocation to walk away with it - a scenario that is perfectly possible with the current allocators. -- 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