xfs
[Top] [All Lists]

Re: [REPOST] [PATCH] fs/xfs/linux-2.6/kmem.c

To: Miquel van Smoorenburg <miquels@xxxxxxxxxxx>
Subject: Re: [REPOST] [PATCH] fs/xfs/linux-2.6/kmem.c
From: Nathan Scott <nathans@xxxxxxx>
Date: Thu, 18 Nov 2004 10:22:47 +1100
Cc: linux-xfs@xxxxxxxxxxx
In-reply-to: <20041115103130.GA7971@cistron.nl>
References: <20041115103130.GA7971@cistron.nl>
Sender: linux-xfs-bounce@xxxxxxxxxxx
User-agent: Mutt/1.5.3i
On Mon, Nov 15, 2004 at 11:31:32AM +0100, Miquel van Smoorenburg wrote:
> I've sent this to the list a month ago, but I think it was overlooked.

Sorry about that.

> I think this (actually, the second patch) should go as a bugfix
> into 2.6.10 ..  So I'm reposting it, if I'm completely wrong about
> this tell me and I'll shut up. Thanks!

Yep, I agree we can certainly improve things, and your patches are
a move in the right direction.  A couple of things:
- I'd prefer to keep the loop, we've been bitten before by "nofail"
allocations, uhm, failing, and ultimately causing corruption.
- should also consider printk_ratelimit, but not clear if that'd be
better "in addition to" or "in place of" the approaches you've taken
so far here.
- it'd be better to keep the manipulation of "retries", esp. the
modulo part till after the first allocation attempt, since the usual
case is for the allocation to succeed, so the fewer instructions we
add in beforehand the better.
- theres a similar spot in xfs_buf.c where we need to retry page
cache allocations when initial attempts don't work out - maybe the
block_congestion check would be useful there too?  Not clear to me
yet though, we may get ourselves in a bind adding that there, but
probably not.

Could you propose a new patch taking these into account?  I think
that'd get us close to something we can merge.

thanks!

-- 
Nathan


<Prev in Thread] Current Thread [Next in Thread>