From: schily@schily.net (Joerg Schilling)
Subject: [TUHS] MacOS X is Unix (tm)
Date: Tue, 03 Jan 2017 14:17:00 +0100 [thread overview]
Message-ID: <586ba44c.dnHd1Caeq6INr3FG%schily@schily.net> (raw)
In-Reply-To: <20170101203813.GV5983@mcvoy.com>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3690 bytes --]
Larry McVoy <lm at mcvoy.com> wrote:
> I'd like to know where you can get a better performing OS. The file systems
> scream when compared to Windows or MacOS, they know about SSDs and do the
> right thing. The processes are light weight, I regularly do "make -j"
> which on my machines just spawns as many processs as needed.
...
> So if I size it to the number of CPUs it is slightly faster. On the other
> hand, when I tell it just spawn as many as it wants it peaks at about 267
> processes running in parallel.
>
> Solaris, AIX, IRIX, HP-UX, MacOS would all thrash like crazy under that
> load, their context switch times are crappy.
>
> Source: author of LMbench which has been measuring this stuff since the
> mid 1990s.
Could you give a verification for this claim please?
My experiences are different.
From what I can tell, the filesystem concepts in Linux are slow and it is
usually not possible to tell what happened in a given time frame. It however
creates the impression that it is fast if you are the only user on a system,
but it makes it hard to gauge a time that is comparable to a time retrived
from a different OS. This is because you usually don't know what happened in
a given time.
If you e.g. use gtar to unpack a Linux kernel archive on your local disk, the
wall clock run time of gtar is low, but it takes some time before the first
disk I/O takes place and the disk I/O continues until a long time after gtar
already returned control to the shell.
If you however use star for the same task and do not specify the "-no-fsync"
option, star takes 4x longer than gtar to return control to the shell. If you
do the same on Solaris using the same hardware, a standard star extract (with
the default fsync) takes only 10% more real time with UFS compared to the time
without fsync and the time is aprox. the same as the unpack time on Linux
using gtar. This is because on Solaris, disk I/O starts immediately even when
you use gtar and there is no time wasted with filling the kernel cache before
I/O starts.
Aprox. 12 years ago, I converted the central web server for the OSS hosting
platform berlios.de (*) (at that time the second largest one) from Linux to
Solaris and the performance did increase ponderably.... Even worse, at the
same time, I did a test where I unpacked the Linux kernel archive using gtar
and switched off the power just after gtar returned control to the shell. The
result was a rotten filesystem that could not be repaired by fsck.
***
So my question is: did you manage to find a method to gauge something
on Linux that is comparable to other platforms or do you also suffer from the
problem that Linux tries to hide the real time needed for filesystem
operations?
***
BTW: ZFS has a similar problem as Linux: It is extremely slow when you ask it
to to things in a way that result in a known state. ZFS however does not result
in a rotten FS when you switch the system off while it is updating the FS.
*) The reason for this conversion was that Linux completely stalled 3-4 times a
day and only a reset did help. There was no way to get the reason for that
problem using Linux debug tools. After the conversion to Solaris, it turned out
that memory overcommitment on Linux was the reason for the freeze. Since we had
two CPUs, the Linux kernel could copy on write pages faster than searching for
processes to kill in order to recover.
Jörg
--
EMail:joerg at schily.net (home) Jörg Schilling D-13353 Berlin
joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/
next prev parent reply other threads:[~2017-01-03 13:17 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <mailman.31.1483203495.3779.tuhs@minnie.tuhs.org>
2016-12-31 22:37 ` David
2016-12-31 23:00 ` Kurt H Maier
[not found] ` <CAH1jEzZ7bqmxtJLSnmd8-_MT4BrgnjgFA2+SvKBQAKou8bZzQw@mail.gmail.com>
[not found] ` <CAH1jEzZMJQAMeZSFFHy1qouDXnq3GqqRa_Fw25i+h9z2FBprHw@mail.gmail.com>
[not found] ` <CAH1jEzYJhRsWhf0BiViignp7_Z-HxNbP7=+ChVbmYErrDQXmsQ@mail.gmail.com>
[not found] ` <CAH1jEzbxDAtpMxCRu1hO2ot2K=Ted0HvpBSx67zOg-FcmqrpaQ@mail.gmail.com>
[not found] ` <CAH1jEzaBMMXdxD7xCaSMM4Ciu0Gg7NktQDeVyLEoHkfYoyerTw@mail.gmail.com>
[not found] ` <CAH1jEzZ6mTDqiGu9pkjg2g3S+Lz2sPVY9Y+16dKSf4dkp5j56Q@mail.gmail.com>
[not found] ` <CAH1jEzaMCWR2xYf-FbifnTj4gWJbCEDJBpCx3r3ErxCnEoXSPg@mail.gmail.com>
[not found] ` <CAH1jEzZWkZ6J0NOifZK05gS+fdKiXQaUZDfvdh56Wm-gsbT4rQ@mail.gmail.com>
[not found] ` <CAH1jEza+2i6jEU5wbxFZ-WUOcGi06zyj5g9Si7RAe5xiety42g@mail.gmail.com>
[not found] ` <CAH1jEza7dHxPmhocSE_CkCPafBgaSS3uYF2g4E_J8gYYdRoVwA@mail.gmail.com>
[not found] ` <CAH1jEzYFXowgA3f=GpJ4HBnAYsyUQLOiZ-uoxryMLZAy5BcsXQ@mail.gmail.com>
[not found] ` <CAH1jEzYcZHkfmFYZRZkmapZxx6q-ZZDSQ-qCzVxDvLsQ0XL6Hg@mail.gmail.com>
[not found] ` <CAH1jEzaqJAuKXOnSvaadoavuQKHf-dT-rtywpdCyFoaWR1k ydQ@mail.gmail.com>
[not found] ` <CAH1jEzaqJAuKXOnSvaadoavuQKHf-dT-rtywpdCyFoaWR1kydQ@mail.gmail.com>
[not found] ` <CAH1jEzbwsEZoADTzBxQQ=OArVc4CLCW8U3e3JmK_BaZzfRjc4A@mail.gmail.com>
[not found] ` <CAH1jEzZ7EG_xYL51uog1ZdaZ1ZMuznS1OkUYYMa9bSJxkQxWrQ@mail.gmail.com>
[not found] ` <CAH1jEzaSJuRkGnVO970JuMnFeht7at2c-L44i1zZ-ejTMdr8Sg@mail.gmail.com>
[not found] ` <CAH1jEzZi2erJEz3fUajE5VxH+3XiWosxfr7ib_r1ZHbdqSFWNg@mail.gmail.com>
[not found] ` <CAH1jEzZmx_4JfdU+HseZzM+F=BvRgUU5brX6A+xkaFbosp8PLg@mail.gmail.com>
[not found] ` <CAH1jEzYjaNVccZtuu4znPPddhGK-DxFdeuV-higNK6dpc9gSqQ@mail.gmail.com>
[not found] ` <CAH1jEzarFb_S4EZ0SAqxTdQr1eD58_G3f3ae0Xtwrmg8VxZGAA@mail.gmail.com>
[not found] ` <CAH1jEzav7rijjpvDrogQKS5dJb09azgnogdGtSsqmPpTHFL7Hg@mail.gmail.com>
[not found] ` <CAH1jEza_oXr33-mjKV7aOVO2U4E953OpQ7dqMABVUp-uix4pJQ@mail.gmail.com>
[not found] ` <CAH1jEzZqs6H9zCyLL1eveAHfEq3SminYBGDyLYwNUxE-h9nDng@mail.gmail.com>
[not found] ` <CAH1jEzb_28daq6EOV1GMg8g-OM_sevbf8_EVE7dprgaVvrMiqA@mail.gmail.com>
2017-01-01 0:43 ` Nick Downing
2017-01-01 10:26 ` Tim Bradshaw
2017-01-01 13:01 ` Ron Natalie
[not found] ` <95D6B274-6D3F-4610-873A-76F4707AE89B@tfe b.org>
2017-01-01 13:56 ` Tim Bradshaw
2017-01-01 19:33 ` David
2017-01-01 20:12 ` Tim Bradshaw
2017-01-03 14:11 ` David
2017-01-01 20:28 ` Kurt H Maier
2017-01-01 20:38 ` Larry McVoy
2017-01-03 13:17 ` Joerg Schilling [this message]
2017-01-03 15:52 ` [TUHS] ZFS (was: Re: MacOS X is Unix (tm)) Michael Kjörling
2017-01-03 16:41 ` Joerg Schilling
2017-01-03 18:20 ` [TUHS] MacOS X is Unix (tm) Larry McVoy
2017-01-06 12:56 ` Joerg Schilling
2017-01-02 10:06 ` arnold
2017-01-02 11:34 ` Ron Natalie
2017-01-02 12:24 ` arnold
2017-01-02 16:42 ` Chet Ramey
2017-01-01 13:28 ` Michael Kjörling
2017-01-02 11:31 ` Joerg Schilling
2017-01-02 16:32 ` Nemo
2017-01-02 16:53 ` Joerg Schilling
2017-01-02 16:44 ` Chet Ramey
2017-01-02 16:49 ` Larry McVoy
2017-01-02 17:02 ` Joerg Schilling
2017-01-02 17:05 ` Chet Ramey
2017-01-02 17:32 ` Larry McVoy
2017-01-02 17:53 ` Chet Ramey
2017-01-02 17:37 ` Christian Neukirchen
2017-01-03 14:06 ` David
2017-01-03 14:33 ` Random832
2017-01-03 15:08 ` Joerg Schilling
2017-01-03 16:09 ` Derek Fawcus
2017-01-03 16:47 ` Joerg Schilling
2017-01-03 17:29 ` Random832
2017-01-03 17:51 ` Joerg Schilling
2017-01-03 14:49 ` Joerg Schilling
2017-01-03 17:39 ` David
2017-01-03 17:59 ` Derek Fawcus
2017-01-03 18:04 ` Joerg Schilling
2017-01-03 18:32 ` Ron Natalie
2017-01-03 18:33 ` Clem Cole
2017-01-03 18:35 ` Clem Cole
2017-01-03 18:45 ` Ron Natalie
2017-03-11 6:35 ` jsteve
2017-03-11 15:36 ` Derrik Walker v2.0
2017-03-11 16:33 ` Paul Winalski
2017-01-03 22:31 ` Random832
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=586ba44c.dnHd1Caeq6INr3FG%schily@schily.net \
--to=schily@schily.net \
/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;
as well as URLs for NNTP newsgroup(s).