You didn't mention an operating system, but I'm pretty sure
`/etc/p6update -nv` works on both OpenServer and UnixWare. Processor
serial numbers are only reported if they're present, which is true only
on Pentium III CPUs. Earlier CPUs didn't have PSNs, and Intel dropped
them in the P4 after so many people complained about supposed privacy
concerns.
`/etc/hw -v -r cpu` will report on the presence of the processor serial
number feature.
>Bela<
Bela Lubkin schrieb:
> Carsten Hammer wrote:
>
>
>>I want to get the cpu serial numbers of all cpus in a machine. How to
>>force to run on a selected cpu?
>>At the moment I get arbitrary cpu serial numbers because sco runs my
>>programm on a arbitrary cpu what is fine most of the time but not at the
>>moment I want to get the serial numbers.
>
>
> You didn't mention an operating system, but I'm pretty sure
> `/etc/p6update -nv` works on both OpenServer and UnixWare. Processor
Oh, I need it for SCO Openserver 5.0.5.
If possible I prefer to have the ability to select the cpu from within
an application written in C or C++.
> serial numbers are only reported if they're present, which is true only
> on Pentium III CPUs. Earlier CPUs didn't have PSNs, and Intel dropped
> them in the P4 after so many people complained about supposed privacy
> concerns.
I prefer to detect the CPU and its ability to deliver a CPU serial
number using my own assembler code. It should work on Linux as well with
changes as small as possible.
Unfortunatly I could not find any way to influence the kernels selection
of the next cpu on a fork. The only thing that I learned is that it
seems to be able to switch cpus off using "cpuonof".
>
> `/etc/hw -v -r cpu` will report on the presence of the processor serial
> number feature.
>
hw -v -r cpu does neither report serial numbers nor the cpu the process
currently runs on. It does not help me unfortunatly.
>
>>Bela<
>
Thanks anyway,
Carsten
> Bela Lubkin schrieb:
> > Carsten Hammer wrote:
> >
> >>I want to get the cpu serial numbers of all cpus in a machine. How to
> >>force to run on a selected cpu?
> >>At the moment I get arbitrary cpu serial numbers because sco runs my
> >>programm on a arbitrary cpu what is fine most of the time but not at the
> >>moment I want to get the serial numbers.
> >
> > You didn't mention an operating system, but I'm pretty sure
> > `/etc/p6update -nv` works on both OpenServer and UnixWare. Processor
>
> Oh, I need it for SCO Openserver 5.0.5.
> If possible I prefer to have the ability to select the cpu from within
> an application written in C or C++.
It can be done, with some root-only ioctls.
> > `/etc/hw -v -r cpu` will report on the presence of the processor serial
> > number feature.
>
> hw -v -r cpu does neither report serial numbers nor the cpu the process
> currently runs on. It does not help me unfortunatly.
Ah, I see that reporting of the Processor Serial Number feature was
added in 5.0.6.
I'll look up the CPU selection ioctls. (Crudely, you can use
lockpid(ADM)...)
>Bela<
> For a shell script solution:
>
> Has anybody ever used lockpid to *start* a prozess on a certain cpu? It should be
> possible using a tricky wrapper script around it by delaying execution of a
> forked process and using lockpid in the meantime, isnt it?
It looks like you don't even have to be very tricky:
# sh -c 'lockpid -l 2 $$; while :; do :; done' &
# sh -c 'lockpid -l 2 $$; while :; do :; done' &
# mpstat
You'll see that CPU 2 is 100% busy, CPU 1 isn't. In each case, '$$' is
the PID of the respective new process. The "while" is being run in the
same process that got locked. Next:
# sh -c 'lockpid -l 2 $$; awk "BEGIN { while(1); }"'&
# sh -c 'lockpid -l 2 $$; awk "BEGIN { while(1); }"'&
# mpstat
Two CPUs will be lit up. `awk` is a subprocess of the locked process,
and locking doesn't carry across to children.
Finally,
# sh -c 'lockpid -l 2 $$; exec awk "BEGIN { while(1); }"'&
# sh -c 'lockpid -l 2 $$; exec awk "BEGIN { while(1); }"'&
# mpstat
Now `awk` is being exec'd within the same process that was locked.
exec(S) does not clear CPU locks.
>Bela<
PS: I was testing this on a 4-CPU box, so I always had spare CPUs to use
for killing these runaways... Except once when I mistakenly locked my
shell onto the same CPU I was abusing. Then things got pretty difficult
for a while. My mistake:
# (lockpid -l 2 $$; while :; do :; done) &
I was using ksh -- not sure if sh would do the same -- '$$' here was the
PID of the parent shell, so I got locked onto CPU 2. Then I ran a
correct statement, locking a runaway onto CPU 2 ... and shell
interaction got really slow. It might be good to use `nice` somewhere
in the equation to make the runaways back off. But I always get
confused about the syntax of `nice`...
Booting from BCP with INITSTATE=S parameter was not successful.
Can you help me?