On 08/14/2011 02:30 PM, Dion Kant wrote: > On 08/14/2011 01:23 PM, Dion Kant wrote: >> Forget >> about the previous results, they will be wrong because of libgcc stream >> buffering and I did not check how these buffers are actually written to >> kernel space. > libgcc uses writev to write out an array of buffers to kernel space > > User bs Actual bs > 1 8191 > 2 8192 > 4 8192 > 8 8192 > 16 8192 > 32 8192 > 64 8192 > 128 8192 > 256 8192 > 512 8192 > 1024 1024 > 2048 2048 > 4096 4096 > 8192 8192 > > Except for writing single user bytes, libgcc does a good job in gathering the > data into buffers with an integral buffer size of 8192 bytes. From a user bs > of 1024 and further, it sticks to this buffer size for writing the data to > kernel space. So that explains the results I obtained with the write method > of ofstream. For all cases the kernel is addressed with a buffer size which > is an integral multiple of 4096 the performance is good. > > I think the one to less buffer size for the single byte case provides an > option for improvement of libgcc. > > Dion
I now think I understand the "strange" behaviour for block sizes not an integral multiple of 4096 bytes. (Of course you guys already knew the answer but just didn't want to make it easy for me to find the answer.) The newer disks today have a sector size of 4096 bytes. They may still be reporting 512 bytes, but this is to keep some ancient OS-es working. When a block write is not an integral of 4096 bytes, for example 512 bytes, 4095 or 8191 bytes, the driver must first read the sector, modify it and finally write it back to the disk. This explains the bi and the increased number of interrupts. I did some Google searches but did not find much. Can someone confirm this hypothesis? Best regards, Dion -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e4ed7e2.6090...@concero.nl
