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 :-).
> 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.
> 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.
- Bart
--
Bart Smaalders Solaris Kernel Performance
barts at cyber.eng.sun.com http://blogs.sun.com/barts
"You will contribute more with mercurial than with thunderbird."
