Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754277Ab1BVOtL (ORCPT ); Tue, 22 Feb 2011 09:49:11 -0500 Received: from mx1.redhat.com ([209.132.183.28]:29222 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754015Ab1BVOtI (ORCPT ); Tue, 22 Feb 2011 09:49:08 -0500 Date: Tue, 22 Feb 2011 15:46:31 +0100 From: Andrea Arcangeli To: Minchan Kim Cc: Andrew Morton , linux-mm , LKML , Steven Barrett , Ben Gamari , Peter Zijlstra , Rik van Riel , Mel Gorman , KOSAKI Motohiro , Wu Fengguang , Johannes Weiner , Nick Piggin , Balbir Singh , KAMEZAWA Hiroyuki Subject: Re: [PATCH v6 0/4] fadvise(DONTNEED) support Message-ID: <20110222144631.GZ13092@random.random> References: <20110221190713.GM13092@random.random> <20110222132804.GQ13092@random.random> <20110222142610.GA6093@barrios-desktop> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110222142610.GA6093@barrios-desktop> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1849 Lines: 36 On Tue, Feb 22, 2011 at 11:26:10PM +0900, Minchan Kim wrote: > I agree your opinion but I hope the patch is going on 2.6.38 or 39. > That's because if we find regression's root cause, how could this series be changed? > I think it's no difference before and after. > Of course, if rsync like applicatoin start to use fadvise agressively, the problem > could be buried on toe but we still have a older kernel and older rsync so we can > reproduce it then we can find the root cause. No risk to hide it (I do backups with tar ;). I'm also assuming your modification to rsync isn't going to be on by default (for small working set, it's ok if rsync holds the cache and doesn't discard it). > What's the problem if the series is merged? > If it is reasonable, it's no problem to pend the series. I've absolutely no problem with the objective of this series. The objective looks very good and it can increase performance (like showed by your benchmark saving 2min from your workload under stress and only running a few seconds slower without stress). > I _totally_ agree your opinion and I want to find root cause of the regression, too. > But unfortunatly, I don't have any time and enviroment to reproduce it. ;( > I hope clever people like you would have a time to find it and report it to linux-mm > in future. > > Ben. Could you test your workload on older 2.6.18 kernel if you see the thread? > It could help us very much. Exactly, I only wanted to suggest to check what happens with 2.6.18 to at least know if it's a regression or not. Because if we have a regression, we need more work on this. -- 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/