From: Robert Cohen <robert.cohen@anu.edu.au>
To: Linus Torvalds <torvalds@transmeta.com>, linux-kernel@vger.kernel.org
Subject: Re: Misaligned write performance
Date: Mon, 29 Oct 2001 20:26:59 +1100 [thread overview]
Message-ID: <3BDD20E3.6AF58BBB@anu.edu.au> (raw)
In-Reply-To: <Pine.LNX.4.33.0110181850001.1489-100000@penguin.transmeta.com>
Linus Torvalds wrote:
>
> > I believe that this is an odd situation and sure it only happens for
> > badly written program. I can see that it would be stupid to optimise for
> > this situation.
> > But do we really need to do this badly for this case?
>
> Well, if you find a real application that cares, I might change my mind,
> but right now read-ahead looks like a waste of time to me.. Does anybody
> really do re-write in practice?
You're right. I don't have a real world program that cares.
The program I have is a thing named lantest which is the standard
benchmark benchmark for macintosh file server performace. Actually as
far as I can tell, the only benchmark available.
The reason am bothered by this case is that I feel its bad practise to
leave degenerate performance situations where the kernel performance
really sucks if it can be easily avoided. If you have a hole in kernel
performce where people can get into degenerate performance, sooner or
later someone is going to fall into it and then they're going to blame
the kernel. Sure this may only happen to badly written programs, but its
not as if the world is exactly short of them.
If you take my situation as a case in point, I was asked to evaluate
Linux and Solaris a potential file serving platforms for Mac clients. So
as part of my testing, I fired up lantest as a benchmark. Solaris was
fine, Linux sucked. My conclusion was that Linux was an immature
operating system that still needed some work and we went with Solaris.
Its only because I devoted time and effort into understanding why Linux
did so badly that I now understand that this is not a Linux problem per
se. And I only did that because I wanted to report the problem and help
Linux become a better operating system.
Anyway, as far as I can tell, it would barely affect Linux performance
to do some read ahead in this case. The disk head is already there, it
costs almost nothing to read a few extra 10's or 100's of K's of data.
And it would help eliminate this potentially degenerate case.
--
Robert Cohen
Unix Support
TLTSU
Australian National University
Ph: 612 58389
prev parent reply other threads:[~2001-10-29 9:30 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <3BCF851D.5080607@anu.edu.au>
2001-10-19 1:56 ` Misaligned write performance: was Re: [Bench] Fileserving performance problems Linus Torvalds
2001-10-29 9:26 ` Robert Cohen [this message]
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=3BDD20E3.6AF58BBB@anu.edu.au \
--to=robert.cohen@anu.edu.au \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@transmeta.com \
/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
all inboxes | Powered by JetHome®