On Wed, 27 May 2009 11:21:53 +0900 Hisashi Hifumi [off-list ref] wrote:

At 11:09 09/05/27, Wu Fengguang wrote:

quoted

On Wed, May 27, 2009 at 08:25:04AM +0800, Hisashi Hifumi wrote:

quoted

At 08:42 09/05/27, Andrew Morton wrote:

quoted

On Fri, 22 May 2009 10:33:23 +0800
Wu Fengguang [off-list ref] wrote:

quoted

quoted

I tested above patch, and I got same performance number.
I wonder why if (PageUptodate(page)) check is there...

Thanks!  This is an interesting micro timing behavior that
demands some research work.  The above check is to confirm if it's
the PageUptodate() case that makes the difference. So why that case
happens so frequently so as to impact the performance? Will it also
happen in NFS?

The problem is readahead IO pipeline is not running smoothly, which is
undesirable and not well understood for now.

The patch causes a remarkably large performance increase.  A 9%
reduction in time for a linear read? I'd be surprised if the workload

Hi Andrew.
Yes, I tested this with dd.

quoted

even consumed 9% of a CPU, so where on earth has the kernel gone to?

Have you been able to reproduce this in your testing?

Yes, this test on my environment is reproducible.

Hisashi, does your environment have some special configurations?

Hi.
My testing environment is as follows:
Hardware: HP DL580 
CPU:Xeon 3.2GHz *4 HT enabled
Memory:8GB
Storage: Dothill SANNet2 FC (7Disks RAID-0 Array)

I did dd to this disk-array and got improved performance number.

I noticed that when a disk is just one HDD, performance improvement
is very small.

Ah.  So it's likely to be some strange interaction with the RAID setup.

I assume that you're using the SANNet 2's "hardware raid"?  Or is the
array set up as jbod and you're using kernel raid0?

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>