Received: by oss.sgi.com id ; Thu, 22 Feb 2001 03:43:24 -0800 Received: from perninha.conectiva.com.br ([200.250.58.156]:4875 "EHLO perninha.conectiva.com.br") by oss.sgi.com with ESMTP id ; Thu, 22 Feb 2001 03:43:09 -0800 Received: from freak.distro.conectiva (freak.distro.conectiva [10.0.17.22]) by perninha.conectiva.com.br (8.9.3/8.9.3) with ESMTP id IAA10227; Thu, 22 Feb 2001 08:42:45 -0300 Date: Thu, 22 Feb 2001 07:56:17 -0200 (BRST) From: Marcelo Tosatti X-Sender: marcelo@freak.distro.conectiva To: Rajagopal Ananthanarayanan cc: dcox@connex.com, Linux-XFS Subject: Re: Repeatable Panics with XFS and RAID1 (long) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Thu, 22 Feb 2001, Marcelo Tosatti wrote: > > > On Wed, 21 Feb 2001, Rajagopal Ananthanarayanan wrote: > > > Danny wrote: > > > > > Feb 20 12:51:38 dsc_proto_1 kernel: __alloc_pages: 0-order allocation > > > failed. > > > > For those seeing __alloc_pages failing, can you please try this patch? > > With recent code changes, writepage() is used for flushing dirty pages, > > and this typically happens under memory pressure. So, doing anything > > expensive to allocate memory under these conditions is bad. > > Ananth, > > I think allocating memory from the atomic queue (used mainly by in > interrupt context) to generate dirty data may cause problems. I'll write the GFP_PAGE_IO thing we talked about RSN to avoid having to use GFP_ATOMIC.