Dhahi374 / likwid

Automatically exported from code.google.com/p/likwid
GNU General Public License v3.0
0 stars 0 forks source link

likwid-pin numbering inside cpuset #177

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
I've got an issue with likwid-pin when run inside a cpuset:

$ likwid-pin -c N:0 ls
INFO: You are running LIKWID in a cpuset with 2 CPUs, only logical numbering 
allowed
ERROR: CPU indices equal to 0 are not allowed
Failed to parse cpulist N:0

$ likwid-pin -c N:1 ls
INFO: You are running LIKWID in a cpuset with 2 CPUs, only logical numbering 
allowed
[likwid-pin] Main PID -> core 19 - OK

Why does the counting start from 1 when inside a cpuset? If you do it outside a 
cpuset, `N:0` is accepted. 

Done with r538

Original issue reported on code.google.com by wpoel...@gmail.com on 3 Apr 2015 at 1:59

GoogleCodeExporter commented 9 years ago
The question was: Should the Lua-API of Likwid be Lua-conform or use the old 
numbering that is not Lua-conform? Lua always starts its indices with 1 and the 
whole API respected this except the cpu expression code. I decided to be 
Lua-conform so all list indicies start with 1 now.

I changed it in revision 535 and starting with this revision N:0 in normal 
environment will not work either because N:x is internally transformed to L:N:x 
and handed over to the logical numbering function. Some for S0:x, C0:x, M0:x.
In my impression the N:x should be x threads in affinity domain N and not 
thread x in affinity domain N but this decision was made long time ago, so I 
don't want to change it now.

Original comment by Thomas.R...@googlemail.com on 7 Apr 2015 at 11:45

GoogleCodeExporter commented 9 years ago
Okay, that's fine by me. As long as the numbering is consistent everywhere.

Original comment by wpoel...@gmail.com on 8 Apr 2015 at 11:45

GoogleCodeExporter commented 9 years ago
The issue seems to be fixed then.

Original comment by Thomas.R...@googlemail.com on 8 Apr 2015 at 3:54