public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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

             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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox