Bart Smaalders wrote:
> Roland Mainz wrote:
> > Right now "isaexec" isn't that bad. However the extra |exec()| becomes
> > an issue in two scenarios:
> > 1. Tiny application with very small runtime (e.g. GNU "echo")
> > 2. Machine with many CPUs - |exec()| must tear down the address space
> > and makes crosscalls to all other CPUs... which will be a problem for
> > the 256CPU Niagara2+ machine... and even more a problem when I read
> > TheRegister.co.uk's article
> > (http://www.theregister.co.uk/2007/07/26/sun_2048_thread_niagara/) about
> > a possible 2048-core machine. 2048-1 crosscalls per |exec()| won't be
> > fun... ;-(
>
> Cross calls limited to the set of CPUs the process has run on so isaexec
> isn't likely to cause a cross call storm unless there are some pathological
> context switching problems :-).
>From what I know there were several high-priority escalations on
SF15K/25K machines last year where Bourne/bash scripts were causing
system-wide performance problems just because they were
|fork()|+|exec()|'ing madly (three solutions: Get rid of the shells
completely, adjust the script code to avoid unneccesary subshells or use
ksh93 (which avoids |fork()|+|exec()| unless it is unavoideable (and
newer versions try to use |posix_spawn()|))) ... and from my own
experience a tight |exec()|-loop can nail large machines (e.g. M8000)
against the next available wall. It sounds that the "pathological case"
happens very often (the problem gets even worse when the application
uses largepages (but don't ask me _why_ this happens...)).
> > That won't work because you have usually more than two entries in the
> > output of /usr/bin/isalist (which is needed to support specially
> > optimized versions for some CPU types like Niagara1 (which doesn't
> > implement all VIS instructions in hardware (which makes the use of
> > -xarch=sparcv8a AFAIK "tricky")) or SPARC64 (which has extra
> > floating-point instructions not available on other SPARC platforms)).
>
> Who uses this w/ isaexec today? As far as I can tell on sun4v systems,
> we use sparcv7 and sparcv9, which would readily be served by the
> proposed mechanism.
I don't know whether we use it this way right now. However we _know_
that it would make sense to ship SSE3 (or which SSE*-thing had the fast
strcopy/compare operations) binaries if SSE3 is supported in hardware.
The same applies for VIS vs. non-VIS in cases like "mplayer"&co.
> > And see CR #6474270 ("isaexec and magical builds" -
> > http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6474270) for
> > another reason why "isaexec" should remain "dynamically" and not turned
> > into a "static" switch.
>
> They can always invoke the version they want directly.
Please read the RFE again - it is needed for development of applications
which should support both 32bit+64bit systems (and just trying to "fix"
the matching build systems is hopeless - it's like trying to boil the
oceans. You can't fix each instance of autoconf&co.) and to handle cases
where only 32bit applications are suiteable for a task (e.g. if a plugin
is needed where the required libraries are only available as 32bit
binaries). Right now the only "workaround" is to become the "root" user
and move the matching binaries around.
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland.mainz at nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
