From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andi Kleen Subject: Re: [PATCH 08/19] ceph: address space operations Date: Thu, 23 Jul 2009 21:16:11 +0200 Message-ID: <20090723191611.GE19207@basil.fritz.box> References: <1248292313-31326-2-git-send-email-sage@newdream.net> <1248292313-31326-3-git-send-email-sage@newdream.net> <1248292313-31326-4-git-send-email-sage@newdream.net> <1248292313-31326-5-git-send-email-sage@newdream.net> <1248292313-31326-6-git-send-email-sage@newdream.net> <1248292313-31326-7-git-send-email-sage@newdream.net> <1248292313-31326-8-git-send-email-sage@newdream.net> <1248292313-31326-9-git-send-email-sage@newdream.net> <874ot33ddd.fsf@basil.nowhere.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Andi Kleen , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org To: Sage Weil Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org > There are two other memory allocations during writeout: a vector of pages > to be written, and the message we're sending to the OSD. If I use a > mempool for those to guarantee as least some writeout will occur, how do I > safely defer when allocations do fail? Will pdflush (or it's replacement) > eventually come back and try ->writepages() again? mempool allocs should never fail, just block for a long time until someone else frees. This means you need to ensure of course you always make forward progress. -Andi -- ak@linux.intel.com -- Speaking for myself only.