Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933220AbZJaTvY (ORCPT ); Sat, 31 Oct 2009 15:51:24 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S933207AbZJaTvW (ORCPT ); Sat, 31 Oct 2009 15:51:22 -0400 Received: from smtp-out.google.com ([216.239.33.17]:5053 "EHLO smtp-out.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933202AbZJaTvV (ORCPT ); Sat, 31 Oct 2009 15:51:21 -0400 DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=date:from:x-x-sender:to:cc:subject:in-reply-to:message-id: references:user-agent:mime-version:content-type:x-system-of-record; b=e3vwMXkguTBJx6oUIjD8D99zimxh8OfHRrd/jIikgbboAyYpMw3kSEZIXZAulPpY+ 12dQcGykxdSWKc/5OO54A== Date: Sat, 31 Oct 2009 12:51:14 -0700 (PDT) From: David Rientjes X-X-Sender: rientjes@chino.kir.corp.google.com To: Pavel Machek cc: Andrew Morton , Mel Gorman , stable@kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, Frans Pop , Jiri Kosina , Sven Geggus , Karol Lewandowski , Tobias Oetiker , KOSAKI Motohiro , Pekka Enberg , Rik van Riel , Christoph Lameter , Stephan von Krawczynski , kernel-testers@vger.kernel.org Subject: Re: [PATCH 2/3] page allocator: Do not allow interrupts to use ALLOC_HARDER In-Reply-To: <20091031184054.GB1475@ucw.cz> Message-ID: References: <1256650833-15516-1-git-send-email-mel@csn.ul.ie> <1256650833-15516-3-git-send-email-mel@csn.ul.ie> <20091027130924.fa903f5a.akpm@linux-foundation.org> <20091031184054.GB1475@ucw.cz> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-System-Of-Record: true Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 826 Lines: 19 On Sat, 31 Oct 2009, Pavel Machek wrote: > > Giving rt tasks access to memory reserves is necessary to reduce latency, > > the privilege does not apply to interrupts that subsequently get run on > > the same cpu. > > If rt task needs to allocate memory like that, then its broken, > anyway... > Um, no, it's a matter of the kernel implementation. We allow such tasks to allocate deeper into reserves to avoid the page allocator from incurring a significant penalty when direct reclaim is required. Background reclaim has already commenced at this point in the slowpath. -- 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/