From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755480AbYDHVNl (ORCPT ); Tue, 8 Apr 2008 17:13:41 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752511AbYDHVNd (ORCPT ); Tue, 8 Apr 2008 17:13:33 -0400 Received: from courier.cs.helsinki.fi ([128.214.9.1]:36679 "EHLO mail.cs.helsinki.fi" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751673AbYDHVNc (ORCPT ); Tue, 8 Apr 2008 17:13:32 -0400 Message-ID: <47FBDF9E.90102@cs.helsinki.fi> Date: Wed, 09 Apr 2008 00:11:58 +0300 From: Pekka Enberg User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: Christoph Lameter CC: Linus Torvalds , Hugh Dickins , Peter Zijlstra , James Bottomley , Andrew Morton , FUJITA Tomonori , Jens Axboe , "Rafael J. Wysocki" , linux-kernel@vger.kernel.org Subject: Re: [PATCH] scsi: fix sense_slab/bio swapping livelock References: <1207598115.29991.23.camel@lappy> <47FA8B5A.5090104@cs.helsinki.fi> <47FA8CB0.6070106@cs.helsinki.fi> <47FA937E.6000009@cs.helsinki.fi> <47FA94AE.4070803@cs.helsinki.fi> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Christoph Lameter wrote: > Hmmmm... Peter has the most experience with these issues. Maybe the best > would be to have this sort of logic in a more general way in the page > allocator? Similar issues surely exist with the page allocator and a fix > there would fix it for all users. This needs some support in the slab allocator anyway. Keep in mind that the patch is specifically addressing writeback in OOM conditions so we must (1) prioritize GFP_TEMPORARY allocations over everyone else (which just get NULL) and (2) use the remaining available memory as efficiently as possible for _all_ GFP_TEMPORARY allocations. Peter is, however, bringing up a good point that my patch doesn't actually _guarantee_ anything so I'm still wondering if this approach makes any sense... But I sure do like Linus' ideas of marking short-lived allocations and trying harder for them in OOM. Pekka