From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S262730AbUGIBxd (ORCPT ); Thu, 8 Jul 2004 21:53:33 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262744AbUGIBxd (ORCPT ); Thu, 8 Jul 2004 21:53:33 -0400 Received: from holomorphy.com ([207.189.100.168]:61928 "EHLO holomorphy.com") by vger.kernel.org with ESMTP id S262730AbUGIBxc (ORCPT ); Thu, 8 Jul 2004 21:53:32 -0400 Date: Thu, 8 Jul 2004 18:53:17 -0700 From: William Lee Irwin III To: Nick Piggin Cc: Peter Osterlund , linux-kernel@vger.kernel.org, Andrew Morton Subject: Re: Can't make use of swap memory in 2.6.7-bk19 Message-ID: <20040709015317.GR21066@holomorphy.com> Mail-Followup-To: William Lee Irwin III , Nick Piggin , Peter Osterlund , linux-kernel@vger.kernel.org, Andrew Morton References: <40ECADF8.7010207@yahoo.com.au> <20040708023001.GN21066@holomorphy.com> <20040708193956.GO21066@holomorphy.com> <40EDED5D.80605@yahoo.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40EDED5D.80605@yahoo.com.au> User-Agent: Mutt/1.5.5.1+cvs20040105i Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org William Lee Irwin III wrote: >> Oh, then I'm stuck in the GFP_WIRED quagmire after all. I guess since >> fixing it involves adding lines I'm in deep trouble. On Fri, Jul 09, 2004 at 10:57:01AM +1000, Nick Piggin wrote: > Or just see if you can tighten up the conditions for OOM to > start with? You must not have seen the patches. the thread starts with Message-id: <0406231407.HbLbJbXaHbKbWa5aJb1a4aKb0a3aKb1a0a2aMbMbYa3aLbMb3aJbWaJbXaMbLb1a342@holomorphy.com> They added a flag indicating wiredness or no to the gfp_mask, which was then propagated down the call chain and eventually passed as an argument to out_of_memory(). In turn, out_of_memory() used the flag to determine whether the nr_swap_pages > 0 check was relevant. i.e. they refined the OOM conditions based on the wiredness of the failing allocation. What probably got the stuff permavetoed was the stats reporting I did along with it that would have been trivial to drop while retaining the needed functional change. The patch was motivated by the nr_swap_pages > 0 check deadlocking. The __GFP_WIRED business was done to discriminate the obvious deadlocking scenario from the false OOM mentioned here. -- wli