From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755020AbYDGVRh (ORCPT ); Mon, 7 Apr 2008 17:17:37 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751785AbYDGVR0 (ORCPT ); Mon, 7 Apr 2008 17:17:26 -0400 Received: from smtp1.linux-foundation.org ([140.211.169.13]:59994 "EHLO smtp1.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751504AbYDGVR0 (ORCPT ); Mon, 7 Apr 2008 17:17:26 -0400 Date: Mon, 7 Apr 2008 14:15:56 -0700 (PDT) From: Linus Torvalds To: Pekka Enberg cc: Hugh Dickins , Peter Zijlstra , Christoph Lameter , 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 In-Reply-To: <47FA8CB0.6070106@cs.helsinki.fi> Message-ID: References: <1207598115.29991.23.camel@lappy> <47FA8B5A.5090104@cs.helsinki.fi> <47FA8CB0.6070106@cs.helsinki.fi> User-Agent: Alpine 1.00 (LFD 882 2007-12-20) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 8 Apr 2008, Pekka Enberg wrote: > > I wonder if we can get away with a SLAB_IO flag that you can use to annotate > caches that participate in writeout and the allocator could keep some spare > pages around that can be handed out for them in case of OOM... Actually, I don't think this is SLAB-specific, since there are potentially the same issues for pages. I suspect the right thing to do is not to mark them for "IO", but mark them for "short-lived", and allow short-lived allocations that don't have extended lifetimes to succeed even when a "real" allocation wouldn't. When we are under memory pressure, a normal allocation generally needs to clear up enough memory from elsewhere to succeed. But a short-lived allocation without any long-term lifetimes would be known to release its memory back to the pool, so it can be allowed to go ahead when a normal memory allocation would not. Examples of short-lived allocations: - IO requests - temporary network packets that don't get queued up (eg "ACK" packet) as opposed to those that do get queued (incoming _or_ outgoing queues) - things like the temporary buffers for "getname()/putname()" etc. That said, even a lot of temporary allocations can at times have issues. If your IO layer is dead, your IO request queues that _should_ have been very temporary may end up staying around for a long time. But I do think that it makes sense to prioritize allocations that are known to be short- lived. (It might also allows us to allocate them from different pools and just generally have other heuristics for cache behaviour - short-lived allocations simply have different behaviour) Linus