Re: [PATCH v6 0/4] fadvise(DONTNEED) support

[Andrea Arcangeli]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/