On Mon, 21 Feb 2005 08:51:32 +0100, Jens Axboe <[EMAIL PROTECTED]> wrote:
> > [EMAIL PROTECTED] ~]# time dd if=/dev/uba of=/dev/null bs=10k count=10240
> > real 0m22.731s
> > [EMAIL PROTECTED] ~]# time dd if=/dev/uba1 of=/dev/null bs=10k count=10240
> > real 1m42.622s
> > So, reading from a partition of the same device is 5 times slower than
> > reading from the device itself. The question is, why?
> I can't explain why the replugging slows it down, maybe you were lucky
> to get contigious pages in the first case? As far as I can see, ub
> effectively disables merging by setting max hw/phys segment limit of 1.
If you mean physical replugging, it has nothing to do with the issue.
I only mentioned it to show that old pages were purged.
Contiguous pages have nothing to do with it either. I forgot to mention
that in the first case (whole device), all reads are done with length of
4KB, while in the second case (partition), all reads are 512 bytes long.
Basically, the key is reading from a partition or not. It causes the
sub-page sized merging to fail.
This is how paritioning looks:
[EMAIL PROTECTED] zaitcev]# fdisk /dev/uba
Command (m for help): p
Disk /dev/uba: 1048 MB, 1048576000 bytes
64 heads, 32 sectors/track, 1000 cylinders
Units = cylinders of 2048 * 512 = 1048576 bytes
Device Boot Start End Blocks Id System
/dev/uba1 * 1 1000 1023983+ 6 FAT16
Partition 1 has different physical/logical endings:
phys=(998, 63, 32) logical=(999, 63, 31)
Command (m for help):
It does not look to me as if the partition started from an odd number
of sectors. In fact, it starts from a full number of pages.
The segment number hint was a good one. I can implement a fake s/g
capability easily within the driver, if this is suggested. But before
hacking on that, I'd like to note that I'm surprised how the block
layer is unable to coalesce sector-sized reads within a page. Also,
why does this depend on partitioning? Something is fishy here.
-- Pete
-
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/
