[Top] [All Lists]

Re: [xfs-masters] [RESEND][PATCH 6/7] xfs: Remove code handling bio_allo

To: Dave Chinner <david@xxxxxxxxxxxxx>
Subject: Re: [xfs-masters] [RESEND][PATCH 6/7] xfs: Remove code handling bio_alloc failure with __GFP_WAIT
From: Nikanth Karthikesan <knikanth@xxxxxxx>
Date: Mon, 20 Apr 2009 13:53:35 +0530
Cc: xfs-masters@xxxxxxxxxxx, Christoph Hellwig <hch@xxxxxxxxxxxxx>, Jens Axboe <jens.axboe@xxxxxxxxxx>, xfs@xxxxxxxxxxx
In-reply-to: <20090420010237.GF16929@xxxxxxxxxxxxxxxx>
Organization: suse.de
References: <200904151609.30677.knikanth@xxxxxxx> <20090420010237.GF16929@xxxxxxxxxxxxxxxx>
User-agent: KMail/1.11.1 (Linux/; KDE/4.2.1; x86_64; ; )
On Monday 20 April 2009 06:32:37 Dave Chinner wrote:
> On Wed, Apr 15, 2009 at 04:09:30PM +0530, Nikanth Karthikesan wrote:
> > Resending as I accidentally missed Jens earlier.
> >
> > Jens, can you merge this as well.
> >
> > Thanks
> > Nikanth
> >
> > Remove code handling bio_alloc failure with __GFP_WAIT.
> > GFP_NOIO implies __GFP_WAIT.
> Not sure that is right. The intent of the code is that if we can't
> get a large bio immediately, try a smaller one which is more likely
> to succeed when we are under memory pressure. i.e. we will get IO
> moving faster than if we waited for a maximally sized biovec to be
> allocated.
> IOWs, I don't think __GFP_WAIT is implied by this code, regardless
> of what GFP_NOIO actually means now. The same code fragment can be
> found in NILFS, and it uses GFP_NOWAIT, not GFP_NOIO. I suspect that
> this is what this XFS code should be changed to use to retain the
> original intent of the code....

Yes, if that is the intent, it needs to be changed as GFP_NOWAIT. Otherwise 
the first attempt to get a larger bio itself would return only after it 
succeeds, which makes the logic useless.


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