[PATCH 0/5] multiple block allocation to current ext3

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Currently ext3_get_block() only map or allocate one block at a time.
This is quite inefficient for sequential IO workload. 

I have posted a early implements a simply multiple block map and
allocation with current ext3.  The basic idea is allocating the 1st
block in the existing way, and attempting to allocate the next adjacent
blocks on a  best effort basis. More description about the
implementation could be found here:
http://marc.theaimsgroup.com/?l=ext2-devel&m=112162230003522&w=2

The following the latest version of the patch: break the original patch
into 5 patches, re-worked some logicals, and fixed some bugs. The break
ups are:

[patch 1] Adding map multiple blocks at a time in ext3_get_blocks()
[patch 2] Extend ext3_get_blocks() to support multiple block allocation
[patch 3] Implement multiple block allocation in ext3-try-to-allocate
(called via ext3_new_block()).
[patch 4] Proper accounting updates in ext3_new_blocks() 
[patch 5] Adjust reservation window size properly (by the given number
of blocks to allocate) before block allocation to increase the
possibility of allocating multiple blocks in a single call.

Tests done so far includes fsx,tiobench and dbench. The following
numbers collected from Direct IO tests (1G file creation/read)  shows
the system time have been greatly reduced (more than 50% on my 8 cpu
system) with the patches.

1G file DIO write:
	2.6.15		2.6.15+patches
real    0m31.275s	0m31.161s
user    0m0.000s	0m0.000s
sys     0m3.384s	0m0.564s 


1G file DIO read:
	2.6.15		2.6.15+patches
real    0m30.733s	0m30.624s
user    0m0.000s	0m0.004s
sys     0m0.748s	0m0.380s

Some previous test we did on buffered IO with using multiple blocks
allocation and delayed allocation shows noticeable improvement on
throughput and system time.

Patches against 2.6.15. Please consider to add to mm tree. 

Thanks!

Mingming

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux