From: Otto Wyss <otto.wyss@bluewin.ch>
To: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Why don't have bits the same rights as humans! (flushing to disk waiting time)
Date: Sun, 19 Aug 2001 23:11:02 +0200 [thread overview]
Message-ID: <3B802B68.ADA545DB@bluewin.ch> (raw)
I recently wrote some small files to the floppy disk and noticed almost nothing
happened immediately but after a certain time the floppy actually started
writing. So this action took more than 30 seconds instead just a few. This
remembered me of the elevator problem in the kernel. To transfer this example
into real live: A person who wants to take the elevator has to wait 8 hours
before the elevator even starts. While probably everyone agrees this is
ridiculous in real live astonishingly nobody complains about it in case of a disk.
Why don't have bits the same rights as humans! ;-)
I know this waiting period should help the elevator algorithm to choose a better
service. But is this really true? Lets assume the following situations:
1. Just a few persons/time period wants to use the elevator. The elevator just
service each person since no other is waiting for its service.
2. A rather lot of persons/time period wants to use the elevator, of course the
elevator can't now service all immediately. But now since accumulation starts
the elevator can improve its service which of course reduces the accumulation
which decreases its service and so on.
3. More persons/time period than the elevator can service wants to use it, the
accumulation always gets higher. Now the elevator works as if it has been given
a large accumulation time. Hopefully this situations doesn't persist or the
system itself gets broke.
Now of course a waiting time helps to push the elevator service into situation 3
even if service request are still in situation 2 or 1. Also real elevators have
this waiting time, it's starts when the first person enters and choose his
destination until it has missed the next person (either direction or already
passed). A rough estimate gives a waiting time in the range of about an average
service time.
If I assume an average service time for bits (disk access) of about 10ms around
3000 service requests could be accumulated before any service starts. Now I dare
to question that even the best elevator algorithm is able to optimize more than
20 service requests on a usefull base, so any waiting time above 200ms is simply useless.
Lets go back to situation 2. As we see accumulation happens on a "natural" way
which imposes a certain waiting time. I guess this alone gives a service which
is at least as good as halve of the best service.
Could anybody produce any real figures to prove/disprove my theory? Could
anybody benchmark the disk access for the 3 waiting times (0, 200ms 30sec) with
different loads?
O. Wyss
Please CC, thanks.
next reply other threads:[~2001-08-19 21:11 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-08-19 21:11 Otto Wyss [this message]
2001-08-19 21:24 ` Why don't have bits the same rights as humans! (flushing to disk waiting time) Ignacio Vazquez-Abrams
2001-08-19 22:16 ` David Ford
2001-08-19 22:36 ` Jakob Østergaard
2001-08-19 22:42 ` Kip Macy
2001-08-20 11:35 ` Helge Hafting
2001-08-25 0:04 ` Dr. Kelsey Hudson
2001-08-25 1:00 ` Daniel Phillips
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=3B802B68.ADA545DB@bluewin.ch \
--to=otto.wyss@bluewin.ch \
--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