Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753093Ab0HYNUu (ORCPT ); Wed, 25 Aug 2010 09:20:50 -0400 Received: from DMZ-MAILSEC-SCANNER-6.MIT.EDU ([18.7.68.35]:51062 "EHLO dmz-mailsec-scanner-6.mit.edu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752468Ab0HYNUs convert rfc822-to-8bit (ORCPT ); Wed, 25 Aug 2010 09:20:48 -0400 X-AuditID: 12074423-b7b19ae0000059ef-70-4c75189c4ed1 Subject: Re: [patch 1/5] mm: add nofail variants of kmalloc kcalloc and kzalloc Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Theodore Tso In-Reply-To: <1282740778.2605.3652.camel@laptop> Date: Wed, 25 Aug 2010 09:20:37 -0400 Cc: David Rientjes , Jens Axboe , Andrew Morton , Neil Brown , Alasdair G Kergon , Chris Mason , Steven Whitehouse , Jan Kara , Frederic Weisbecker , "linux-raid@vger.kernel.org" , "linux-btrfs@vger.kernel.org" , "cluster-devel@redhat.com" , "linux-ext4@vger.kernel.org" , "reiserfs-devel@vger.kernel.org" , "linux-kernel@vger.kernel.org" Content-Transfer-Encoding: 8BIT Message-Id: References: <1282656558.2605.2742.camel@laptop> <4C73CA24.3060707@fusionio.com> <20100825112433.GB4453@thunk.org> <1282736132.2605.3563.camel@laptop> <20100825115709.GD4453@thunk.org> <1282740516.2605.3644.camel@laptop> <1282740778.2605.3652.camel@laptop> To: Peter Zijlstra X-Mailer: Apple Mail (2.1081) X-Brightmail-Tracker: AAAAAA== Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1278 Lines: 20 On Aug 25, 2010, at 8:52 AM, Peter Zijlstra wrote: > Also, there's a good reason for disliking (a), its a deadlock scenario, > suppose we need to write out data to get free pages, but the writing out > is blocked on requiring free pages. > > There's really nothing the page allocator can do to help you there, its > a situation you have to avoid getting into. Well, if all of these users start having their own private pools of emergency memory, I'm not sure that's such a great idea either. And in some cases, there *is* extra memory. For example, if the reason why the page allocator failed is because there isn't enough memory in the current process's cgroup, maybe it's important enough that the kernel code might decide to say, "violate the cgroup constraints --- it's more important that we not bring down the entire system" than to honor whatever yahoo decided that a particular cgroup has been set down to something ridiculous like 512mb, when there's plenty of free physical memory --- but not in that cgroup. -- Ted -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/