From: Russell Coker <russell@coker.com.au>
To: linux-kernel@vger.kernel.org
Cc: herbert@gondor.apana.org.au
Subject: struct stat{st_blksize} for /dev entries in 2.4.3
Date: Sun, 8 Apr 2001 23:49:19 +1000 [thread overview]
Message-ID: <01040823491919.25703@lyta> (raw)
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
next reply other threads:[~2001-04-08 13:51 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-04-08 13:49 Russell Coker [this message]
2001-04-08 18:46 ` struct stat{st_blksize} for /dev entries in 2.4.3 Ulrich Drepper
2001-04-09 7:32 ` Eric W. Biederman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=01040823491919.25703@lyta \
--to=russell@coker.com.au \
--cc=herbert@gondor.apana.org.au \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.