Message-ID: <41544876.4040302@yahoo.com.au>
Date: Sat, 25 Sep 2004 02:16:54 +1000
From: Nick Piggin <nickpiggin@yahoo.com.au>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040820 Debian/1.7.2-4
MIME-Version: 1.0
To: Steven Pratt <slpratt@austin.ibm.com>
CC: Andrew Morton <akpm@osdl.org>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH/RFC] Simplified Readahead
References: <4152F46D.1060200@austin.ibm.com> <20040923194216.1f2b7b05.akpm@osdl.org> <41543FE2.5040807@austin.ibm.com>
In-Reply-To: <41543FE2.5040807@austin.ibm.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1248
Lines: 35

Steven Pratt wrote:
> Andrew Morton wrote:
> 
>> Steven Pratt <slpratt@austin.ibm.com> wrote:
>>  
>>
>>> would like to offer up an alternative simplified design which will 
>>> not only make the code easier to maintain,
>>>   
>>
>>
>> We won't know that until all functionality is in place.
>>  
>>
> Ok, but both you and Nick indicated that the queue congestion isn't 
> needed,

I would have thought that always doing the readahead would provide a
more graceful degradation, assuming the readahead algorithm is fairly
accurate, and copes with things like readahead thrashing (which we
hope is the case).

>> I do think we should skip the I/O for POSIX_FADV_WILLNEED against a
>> congested queue.  I can't immediately think of a good reason for skipping
>> the I/O for normal readahead.
>>  

I don't see why you should skip the readahead for FADVISE_WILLNEED
either. Presumably if someone needs this, they really need it. We
should aim for optimal behaviour when the apis are being used correctly...
-
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/