Re: [git patches] IDE update

2005-07-08 Thread Steven Pratt
Jens Axboe wrote: On Fri, Jul 08 2005, Andrew Morton wrote: Jens Axboe <[EMAIL PROTECTED]> wrote: Some more investigation - it appears to be broken read-ahead, actually. hdparm does repeated read(), lseek() loops which causes the read-ahead logic to mark the file as being in cache (sin

Re: 2.6.12-rc2-mm3

2005-04-12 Thread Steven Pratt
Andrew Morton wrote: Nick Piggin <[EMAIL PROTECTED]> wrote: AS basically does its own TCQ strangulation, which IIRC involves things > > like completing all reads before issuing new writes, and completing all > > reads from one process before reads from another. As well as the > > fun

Re: 2.6.12-rc2-mm3

2005-04-12 Thread Steven Pratt
Andrew Morton wrote: Nick Piggin <[EMAIL PROTECTED]> wrote: - The effects of tcq on AS are much less disastrous than I thought they > were. Do I have the wrong workload? Memory fails me. Or did we fix the > anticipatory scheduler? > > Yes, we did fix it ;) Quite a long time ago, so m

Re: [PATCH 2/2] readahead: improve sequential read detection

2005-03-09 Thread Steven Pratt
Ram wrote: On Wed, 2005-03-02 at 11:08, Oleg Nesterov wrote: ..snip... @@ -527,7 +527,7 @@ page_cache_readahead(struct address_spac } out: - return newsize; + return ra->prev_page + 1; This change introduces one key behavioural change in page_cache_readahead(). Instead of returning

Re: [PATCH 4/4][RESEND] readahead: cleanup blockable_page_cache_readahead()

2005-02-24 Thread Steven Pratt
Ram wrote: Andrew, I have verified the patches against my standard benchmarks and did not see any bad effects. Also I have reviewd the patch and it looked clean and correct. RP I have not had a chance to benchmark, but visual inspection looks good. Steve On Thu, 2005-02-24 at 11:37,

Re: [PATCH 3/4] readahead: factor out duplicated code

2005-02-02 Thread Steven Pratt
Oleg Nesterov wrote: This patch introduces make_ahead_window() function for simplification of page_cache_readahead. Signed-off-by: Oleg Nesterov <[EMAIL PROTECTED]> --- 2.6.11-rc2/mm/readahead.c~ 2005-01-27 22:14:39.0 +0300 +++ 2.6.11-rc2/mm/readahead.c 2005-01-29 15:51:04.0 +030

Re: [PATCH 2/4] page_cache_readahead: remove duplicated code

2005-01-25 Thread Steven Pratt
Ram wrote: On Tue, 2005-01-25 at 03:59, Oleg Nesterov wrote: Cases "no ahead window" and "crossed into ahead window" can be unified. No. There is a reason why we had some duplication. With your patch, we will end up reading-on-demand instead of reading ahead. When we notice a sequential re

Re: [PATCH 4/4] blockable_page_cache_readahead() cleanup

2005-01-25 Thread Steven Pratt
No problem with this patch either. Again, not sure it buys much but it should work fine. Steve Oleg Nesterov wrote: I think that do_page_cache_readahead() can be inlined in blockable_page_cache_readahead(), this makes the code a bit more readable in my opinion. Also makes check_ra_success() stat

Re: [PATCH 3/4] cleanup ahead window calculation

2005-01-25 Thread Steven Pratt
Not sure how much better this is, but it doesn't hurt anything. Steve Oleg Nesterov wrote: This patch moves some code into the get_next_ra_size() and renames it into 'set_next_ahead_window'. Signed-off-by: Oleg Nesterov <[EMAIL PROTECTED]> --- 2.6.11-rc2/mm/readahead.c~ 2005-01-25 15:17:13.000

Re: [PATCH 2/4] page_cache_readahead: remove duplicated code

2005-01-25 Thread Steven Pratt
I like this one, especially getting rid of the large duplicate comment. No functional difference. Signed-off-by: Steven Pratt <[EMAIL PROTECTED]> Oleg Nesterov wrote: Cases "no ahead window" and "crossed into ahead window" can be unified. Signed-off-by: Oleg

Re: [PATCH 1/4] page_cache_readahead: unneeded prev_page assignments

2005-01-25 Thread Steven Pratt
Looks fine, thought we had some reason for it in the past, but it will definitly be overwritten. Signed-off-by: Steven Pratt <[EMAIL PROTECTED]> Oleg Nesterov wrote: There is no point in setting ra->prev_page before 'goto out', it will be overwritten anyway. Signed-off-by: Ol

[PATCH] 2.4.0-test10 zap_page_range

2000-11-06 Thread Steven Pratt
Back in April there was some discussion about the race condition where a call to zap_page_range followed by a call to flush_tlb_range allows for a page which has been freed to be re-allocated on a different cpu and referenced via a tlb on a third cpu before the tlb is actually flushed. Below is a

Re: [PATCH] 2.4.0-test10-pre6 TLB flush race in establish_pte

2000-10-31 Thread Steven Pratt
Andrea Arcangeli wrote: > > On Mon, Oct 30, 2000 at 03:31:22PM -0600, Steve Pratt/Austin/IBM wrote: > > [..] no patch ever > > appeared. [..] > > You didn't followed l-k closely enough as the strict fix was submitted two > times but it got not merged. (maybe because it had an #ifdef __s390__ tha