linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andi Kleen <andi@firstfloor.org>
To: David Newall <davidn@davidnewall.com>
Cc: Andi Kleen <andi@firstfloor.org>,
	akpm@osdl.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH for mm] Remove iBCS support
Date: Sun, 20 Jan 2008 06:55:44 +0100	[thread overview]
Message-ID: <20080120055544.GB19861@one.firstfloor.org> (raw)
In-Reply-To: <4792DD22.4070902@davidnewall.com>

On Sun, Jan 20, 2008 at 04:03:22PM +1030, David Newall wrote:
> It's not necessarily that simple.  It might be for KFC and Dominoes, but
> for others, SCO is not the complete story.  Many legacy systems are
> written in COBOL, and must pay a per-seat licence for that on top of the
> per-seat licence for UNIX.  It is these systems that are most attracted
> towards SCO compatibility.

Well I'm sure if they migrate they can either recompile or pay someone
to forward port and apply and support the iBCS emulation patchkit.
And for that person it will be only a few minutes to readd these hunks.

However it doesn't make any sense to have all Linux systems ever
out there who can't even run these binaries without significantly
changing the kernel have carry the overhead of these unnecessary checks.

> 
> >>> But it does not make sense for all Linux kernels to always check for iBCS executables
> >>> when they don't have to code to run them anyways.
> >>>   
> >>>       
> >> I don't suppose you're suggesting this will make a big difference.  Even
> >> if every exec did nothing but immediately exit, it still wouldn't make
> >> much difference.
> >>     
> >
> > It's not a big difference, but why do unnecessary work on all 
> > Linux kernels? There are a lot of Linux machines out there and 
> > if all of them only do a little unnecessary work each fork()
> > over a year it adds up to really a lot of wasted cycles.
> >   
> 
> It still adds up to something that nobody can perceive, not even using a
> very fine stopwatch and counting over a period of years.

I'm not sure the cost is that low because they access one (or more likely
two) out of line data cache line for the two strings and kernel often runs
cache cold because userland tends to fill the caches and then a cache miss
can be actually hundreds of cycles, possibly multiplied by two.

But assuming there is no cache miss (which is a very conservative
assumption) and the strcmps cost 20 cycles and you got 1 million
2Ghz Linux systems out there doing 100k execs each day we're talking
about 1000 CPU seconds wasted each day. That should be certainly
measurable on most stop watches.

> 
> > Especially since the few people who might really
> > need it can easily readd it.
> >   
> No.  Very few people can add it, easily or otherwise.

They have to patch the kernel in non trivial ways anyways because they
would need to patch in the whole old iBCS emulation layer.

(e.g. the old default ldt code which was for iBCS was just dropped --
strangely you didn't raise your voice against that)

>  Perhaps KFC could
> employ somebody to add it, but they'd more likely be able to convert
> their entire software stack instead.  The paint shops and mechanics of
> the world would have little chance of that.

Sorry, but I don't think you know what you're talking about here.

-Andi


  reply	other threads:[~2008-01-20  5:52 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-19  4:59 [PATCH for mm] Remove iBCS support Andi Kleen
2008-01-20  2:27 ` David Newall
2008-01-20  3:11   ` Andi Kleen
2008-01-20  4:46     ` David Newall
2008-01-20  5:18       ` Andi Kleen
2008-01-20  5:33         ` David Newall
2008-01-20  5:55           ` Andi Kleen [this message]
2008-01-20  6:23             ` David Newall
2008-01-20  7:29               ` Andi Kleen
2008-01-21  1:37                 ` David Newall
2008-01-22 10:24                   ` Karl Kiniger
2008-01-22 15:06                     ` David Newall
2008-01-22 15:52                       ` Adrian Bunk
2008-01-23  8:48                     ` Andi Kleen
2008-01-23 14:12                       ` Karl Kiniger
2008-01-23 14:24                         ` Andi Kleen
2008-01-24 17:06                           ` David Newall
2008-01-22 11:12                   ` Ingo Molnar
2008-01-22 12:42                     ` Karl Kiniger
2008-01-22 15:13                     ` David Newall
2008-01-22 15:49                       ` Ingo Molnar
2008-01-24 17:01                         ` David Newall
2008-01-22 16:01                       ` Adrian Bunk
2008-01-24 17:04                         ` David Newall
2008-01-24 17:24                           ` Adrian Bunk
2008-01-24 17:55                             ` David Newall
2008-01-24 18:14                               ` Adrian Bunk
2008-01-25  2:14                                 ` David Newall
2008-01-25  5:12                                   ` Valdis.Kletnieks
2008-01-25 16:40                                   ` Alan Cox
2008-01-24 19:51                               ` Pavel Machek
2008-01-25  2:17                                 ` David Newall
2008-01-24 20:37                               ` Andi Kleen
2008-01-25  2:16                                 ` David Newall
2008-01-22 16:50                       ` Alan Cox
2008-01-24 17:08                         ` David Newall
2008-01-22 13:20                 ` Giulio
2008-01-20 13:06           ` Alan Cox
2008-01-20 13:43             ` David Newall
2008-01-20 13:51               ` Alan Cox
2008-01-25 12:17 ` Ingo Molnar

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=20080120055544.GB19861@one.firstfloor.org \
    --to=andi@firstfloor.org \
    --cc=akpm@osdl.org \
    --cc=davidn@davidnewall.com \
    --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;
as well as URLs for NNTP newsgroup(s).