Prev: Can't roll the log for ....
Next: usb stick volume label
From: Casper H.S. Dik on 27 Mar 2006 08:04
"Dave (from the UK)" <see-my-signature(a)southminster-branch-line.org.uk> writes:

>Thanks for that. I have compiled it 64 bit, as the Mathematica kernel is 64-bit.

>% cc -xtarget=ultra -xarch=v9 -G -Kpic select_preload.c -o select_preload.so
>su
># mv select_preload.so /usr/local/lib/

>The 64-bit kernal gets started by the front end. The front end calls
>a script which starts the kernel. The script ends in the line:

>exec "${MathKernel}" "$@"

>I'm not sure how I should alter that line, but I tried:

>LD_PRELOAD=/usr/local/lib/select_preload.so exec "${MathKernel}" "$@"

Try:

LD_PRELOAD_64=...

also, the above syntax does not work with "exec":

FOO=bar exec sh
echo $FOO
# Nothing

>That did not effect the CPU usage.

So try again:

LD_PRELOAD_64=/usr/local/lib/select_preload.so
export LD_PRELOAD_64
exec "${MathKernel}" "$@"

>I guess there might be some point in starting the kernal with
>truss and logging the data?

Sure.

Casper
From: Dave (from the UK) on 27 Mar 2006 08:25
Casper H.S. Dik wrote:

>>That did not effect the CPU usage.
>
>
> So try again:
>
> LD_PRELOAD_64=/usr/local/lib/select_preload.so
> export LD_PRELOAD_64
> exec "${MathKernel}" "$@"

Cheers, you are a genius, that works.

CPU usage is now sensible

sparrow / % prstat
PID USERNAME SIZE RSS STATE PRI NICE TIME CPU PROCESS/NLWP
6705 drkirkby 235M 168M sleep 49 0 0:58:42 1.2% mozilla-bin/3
6453 drkirkby 189M 87M sleep 59 0 0:28:24 0.9% Xsun/1
6758 drkirkby 103M 41M sleep 59 0 0:05:22 0.8% gnome-terminal/2
8305 drkirkby 205M 103M sleep 49 0 0:08:30 0.4% acroread/1
6688 drkirkby 233M 64M sleep 49 0 0:11:51 0.3% java/21
20422 drkirkby 63M 18M sleep 59 0 0:00:04 0.3% MathKernel/3
6611 drkirkby 80M 25M sleep 59 0 0:08:05 0.2% metacity/1
6617 drkirkby 76M 18M sleep 59 0 0:00:18 0.2% nautilus/5
6630 drkirkby 74M 16M sleep 49 0 0:03:46 0.2% wnck-applet/1

MathKernel has only used 4 seconds despite having been run a
few minutes and done a couple of simple calculations.

You always seem to be able to solve any problems I have with commercial
software (remember the 'ib' driver for the National Instruments
GPIB card?) that the vendors can't work out.


>>I guess there might be some point in starting the kernal with
>>truss and logging the data?
>
>
> Sure.

Not much point now!!

>
> Casper


Cheers, Dave
--
Dave K MCSE.

MCSE = Minefield Consultant and Solitaire Expert.

Please note my email address changes periodically to avoid spam.
It is always of the form: month-year(a)domain. Hitting reply will work
for a couple of months only. Later set it manually.
From: Casper H.S. Dik on 27 Mar 2006 09:16
"Dave (from the UK)" <see-my-signature(a)southminster-branch-line.org.uk> writes:

>Cheers, you are a genius, that works.

Thanks :-)

>You always seem to be able to solve any problems I have with commercial
>software (remember the 'ib' driver for the National Instruments
>GPIB card?) that the vendors can't work out.

I remember. It's not entirely fair to blame the vendors for not
understanding Solaris as well as a Solaris engineer.

In this particular case, I think it's a real Solaris bug:

6404383 select() behaviour changed in Solaris 10, breaking binary compatibility

The "1us" select() was understood as "poll for the shortest time possible"
and not poll and return immediately.

>Not much point now!!

Indeed.

as you can see, maintaining binary compatibility is *really* hard because
every change can be an incompatible one.

In Solaris 9 and before, we had just the "poll" system call as a
building block for select() and this caused the time to be round up
to 1ms.

In Solaris 10 came pselect() which uses a "struct timespec" (nano seconds)
and which adds a signal mask. The signal mask required a new interface
so we added pollsys() which is based on poll but carries a signal mask
and a struct timespec argument. poll, select and pselect were (re)written
to use the new interface and so select() now passes 1us to the kernel.
This then causes a failure on slow hardware (but on a 1.2GHz it also
can't always doe the pre-work in under 1us)

I think that we will round up the select timeout to 1ms again in the
library for select() (not for pselect() as the new code can be written
to live with this behaviour)

The program below should finish in 5 seconds, but runs much more quickly
on slower hardware.

/*
* Demo bug 6404383: program finishes much more quickly on slow
* system, pegging CPU at 100%.
*/
#include <sys/time.h>
#include <sys/param.h>
#include <stdio.h>
#include <string.h>

int
main(int argc, char **argv)
{
static struct timeval tv = { 0, 1 };
hrtime_t start, end;
int i;
int count = HZ * 5;
fd_set fdr;
int s1, sx;

FD_ZERO(&fdr);
start = gethrtime();
for (i = 0; i < count; i++) {
FD_SET(0, &fdr);
(void) select(3, &fdr, NULL, NULL, &tv);
}
end = gethrtime();

s1 = (int)((end - start)/count);
sx = 1000000000/HZ;
(void) printf("ns/call = %d, expected = %d (%.2f times too fast)\n",
s1, sx, (double)sx/s1);

}

Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
From: Dave (from the UK) on 27 Mar 2006 09:55
Casper H.S. Dik wrote:
> "Dave (from the UK)" <see-my-signature(a)southminster-branch-line.org.uk> writes:
>
>
>>Cheers, you are a genius, that works.
>
>
> Thanks :-)
>
>
>>You always seem to be able to solve any problems I have with commercial
>>software (remember the 'ib' driver for the National Instruments
>>GPIB card?) that the vendors can't work out.
>
>
> I remember. It's not entirely fair to blame the vendors for not
> understanding Solaris as well as a Solaris engineer.
>

True.

And in the 'ib' case, it seems to me Sun should have an agreed
convention for naming drivers, not just people picking names at random.

> In this particular case, I think it's a real Solaris bug:

I'm sure Wolfram Research will be glad to know Mathematica is not at fault!

> 6404383 select() behaviour changed in Solaris 10, breaking binary compatibility

Is that a bug that was already in the Sun database, or one you submitted
today?

> as you can see, maintaining binary compatibility is *really* hard because
> every change can be an incompatible one.

Yes, I can see that. But if you don't make changes, you don't make
progress.

I'll post some sort of summary of this to comp.soft-sys.math.mathematica
and sci.math.symbolic. It will take some time to appear, as
comp.soft-sys.math.mathematica is moderated. I can't say I am too keen
on moderated newsgroups myself. (In case you don't know, the moderator
of comp.soft-sys.math.mathematica is Steve of the Sunfreeware site)

--
Dave K MCSE.

MCSE = Minefield Consultant and Solitaire Expert.

Please note my email address changes periodically to avoid spam.
It is always of the form: month-year(a)domain. Hitting reply will work
for a couple of months only. Later set it manually.
From: INVALID-see-signature-for-how-to-determine on 27 Mar 2006 10:33
Casper H.S. Dik wrote:
> solaris10 % truss -v pollsys -p 6205
> /3: pollsys(0xFFFFFFFF79A75450, 1, 0xFFFFFFFF79AF5510,
0x00000000) = 0
> /3: fd=23 ev=POLLRDNORM rev=0
> /3: timeout: 0.000001000 sec
>
>
> Hm, this timeout value looks suspicious.
>
> They might be calling select() with the smallest possible timeout
(1us)
> which would map to 1ms poll in S9 but 1us pollsys in S10.
>
Ah, that makes some sense.

> Inspecting the code, it seems that pollsys() uses a cv_timedwait()
which
> uses the real time to compute when it needs to wakeup.
>
Cheers.

> Because the *slow* systems can't manage poll setup in under 1us,
> they will hit cv_timedwait when we're past the 1us mark and the
> function will return immediately. Fast systems, OTOH, will be able
> to make the 1us deadline and cv_timedwait will sleep until the next
> clocktick.
>
> If this hypothesis is correct, then perhaps the following preload
> will work (preload w/ LD_PRELOAD=...); different options for 64 bit
> executable.
>
> /*
> * Select roundup preload. (casper.dik(a)you.know.where)
> * cc -G -Kpic select_preload.c -o select_preload.so
> *
> */
>
<snip>

Thanks for that. I have compiled it 64 bit, as the Mathematica kernel
is 64-bit.

% cc -xtarget=ultra -xarch=v9 -G -Kpic select_preload.c -o
select_preload.so
su
# mv select_preload.so /usr/local/lib/

The 64-bit kernal gets started by the front end. The front end calls
a script which starts the kernel. The script ends in the line:

exec "${MathKernel}" "$@"

I'm not sure how I should alter that line, but I tried:

LD_PRELOAD=/usr/local/lib/select_preload.so exec "${MathKernel}" "$@"

That did not effect the CPU usage.

I guess there might be some point in starting the kernal with
truss and logging the data?

--
Dave K MCSE.

MCSE = Minefield Consultant and Solitaire Expert.

Please note my email address changes periodically to avoid spam.
It is always of the form: month-year(a)domain. Hitting reply will work
for a couple of months only. Later set it manually.

First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: Can't roll the log for ....
Next: usb stick volume label