When you stat() the files under /dev the st_blksize is returned as 1024
bytes. Currently cat will look at the input block size and the output block
size and use the maximum of them as it's buffer size. I believe that
programs such as cat should never use a buffer size smaller than a page of
memory and reported this as a bug in cat.
Herbert Xu (the maintainer of the Debian package textutils which contains
cat) considers that the device should return a larger number in the
st_blksize.
Here are some test results, first a P3-650 with 256M of RAM using a 300M
partition of a 10G disk:
root@lyta:/#time cat /dev/ide/host0/bus0/target0/lun0/part1 > /dev/null
real 0m37.959s
user 0m0.220s
sys 0m4.910s
My patched cat uses 25% of the user CPU time and 90% the system CPU time of
the unpatched cat:
root@lyta:/#time /usr/src/textutils-new/src/cat
/dev/ide/host0/bus0/target0/lun0/part1 > /dev/null
real 0m35.502s
user 0m0.060s
sys 0m4.440s
Now here's an AMD K6-350 with 64M of RAM using a 2G RAID-1 partition across
two 46G disks:
root@ivanova:~#time cat /dev/md/1 > /dev/null
real 2m25.906s
user 0m2.200s
sys 1m16.290s
My patched cat uses 30% the user CPU time and 95% the system CPU time:
root@ivanova:~#time /tmp/cat /dev/md/1 > /dev/null
real 2m14.845s
user 0m0.720s
sys 1m12.030s
On an AMD Athlon 800 machine I noticed an even more significant difference
(the command "cat /dev/zero > /dev/hdc1" was using 100% CPU time but the disk
was not at maximum speed before I patched cat). But I don't have suitable
test results with me at this time so I can't give you the details. Another
issue is that an Athlon 800 is a reasonably fast CPU, and it should probably
be able to handle 33000 reads and 33000 writes per second easily without
using any significant amount of CPU time.
Now I would like some comments on the following issues:
Is this a bug in cat regardless of whether the behaviour of the kernel is
right or wrong? I have attached a patch for cat in case it is determined
that cat is buggy.
Regardless of whether cat is doing the right thing or not, does it make sense
for the st_blksize of /dev/* to be 1024 bytes? Or should it be 4096?
My understanding is that the st_blksize is the recommended IO size (not
mandatory). So it shouldn't break anything if this is set to a minimum of
the page size. But setting it to the page size will hint that applications
should use a page as the minimum IO block size and cause some applications to
deliver better performance.
diff -ru textutils-2.0/src/cat.c textutils-new/src/cat.c
--- textutils-2.0/src/cat.c Sun Apr 8 22:55:10 2001
+++ textutils-new/src/cat.c Sun Apr 8 23:23:54 2001
@@ -790,6 +790,9 @@
if (options == 0)
{
insize = max (insize, outsize);
+#ifdef _SC_PHYS_PAGES
+ insize = max (insize, sysconf(_SC_PAGESIZE));
+#endif
inbuf = (unsigned char *) xmalloc (insize);
simple_cat (inbuf, insize);
-- http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/projects.html Projects I am working on http://www.coker.com.au/~russell/ My home page - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Apr 15 2001 - 21:00:10 EST