Open MPI logo

Hardware Locality Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Hardware Locality Development mailing list

Subject: Re: [hwloc-devel] lstopo - please add the information about the kernel to the graphical output
From: Brice Goglin (Brice.Goglin_at_[hidden])
Date: 2013-08-29 11:44:39


Le 29/08/2013 15:46, Jiri Hladky a écrit :
> Hi Brice,
>
> I'm sorry I have missed that e-mail. I agree that the output as
> originally requested would very long or take multiple lines.
>
> So what about this compromise - let's put into the graphical output
> only release tag (uname_buf.release)
>
> uname -r
> 3.10.7-100.fc18.x86_64
>

That's not a "portable" solution for showing something useful:
On Debian, it's not perfect, you just get 3.10-2-amd64 but not the
3.10.5 hidden in there (need uname -v for that)
On AIX 6.1, you just get "1" (need uname -v for the "6")
On BSD, uname -r isn't too bad, uname -v sometimes help, but sometimes
it's veeeeeeery long.

Maybe just forget about the automatic way and let you call lstopo with
something like --annotate-legend "Release: $(uname -r)" (and you deal
with length constraints) ?

Brice

> It's short and has the most important information.
>
> What do you think?
>
> Jirka
>
>
> On Tue, Aug 27, 2013 at 6:19 PM, Brice Goglin <Brice.Goglin_at_[hidden]
> <mailto:Brice.Goglin_at_[hidden]>> wrote:
>
> The problem I have while playing with this is that it takes a lot
> of space. Putting the entire uname on a single line will be
> truncated when the topology drawing isn't large (on machines with
> 2 cores for instance). And using multiple lines would make the
> legend huge.
> We could make it optional. But if you have to remember to manually
> enable this new option, why not just remember to export to XML
> instead, you already have all uname info in there.
>
>
> Brice
>
>
>
> Le 26/08/2013 15:11, Jiri Hladky a écrit :
>> Hi Brice,
>> hi all,
>>
>> I do run hwloc on different versions of Linux kernel when testing
>> RHEL. Since sometimes kernel is buggy and does not detect the
>> topology correctly it would be useful to have at the bottom of
>> the graphical output of the lstopo not only host name but also
>> the version of the kernel.
>>
>> Example of C code on Linux to write this info:
>> ===============================================
>> #include <sys/utsname.h>
>> if(uname(&uname_buf) == -1)
>> printf("uname call failed!");
>> else {
>> printf("Nodename:\t%s\n", uname_buf.nodename);
>> printf("Sysname:\t%s\n", uname_buf.sysname);
>> printf("Release:\t%s\n", uname_buf.release);
>> printf("Version:\t%s\n", uname_buf.version);
>> printf("Machine:\t%s\n", uname_buf.machine);
>> }
>>
>> Nodename: localhost.localdomain
>> Sysname: Linux
>> Release: 3.10.7-100 <tel:3.10.7-100>.fc18.x86_64
>> Version: #1 SMP Thu Aug 15 22:21:29 UTC 2013
>> Machine: x86_64
>> ===============================================
>>
>>
>> Suggestion: on the graphical output of lstopo please add the line
>>
>> System: Linux, x86_64, 3.10.7-100 <tel:3.10.7-100>.fc18.x86_64 #1
>> SMP Thu Aug 15 22:21:29 UTC 2013
>>
>>
>> printf("System: %s, %s, %s %s\n", uname_buf.sysname,
>> uname_buf.machine, uname_buf.release, uname_buf.version);
>>
>> Would it be possible? Any further ideas, suggestions?
>>
>> Thanks a lot!
>> Jirka
>>
>> On Tue, Jun 18, 2013 at 5:17 PM, Jiri Hladky
>> <hladky.jiri_at_[hidden] <mailto:hladky.jiri_at_[hidden]>> wrote:
>>
>> Hi Brice,
>>
>> we test linux kernel job scheduler. To do so, we run for example
>>
>> 1
>> 2
>> ....
>> 16
>> 32 linpack benchmarks simultaneously.
>> (upto the number of cores)
>>
>> For each group of jobs we have this output:
>>
>> =======2 simultaneous jobs========
>> PID #CPU #CPU #CPU #CPU
>> PID #CPU #CPU #CPU
>> ==============================
>>
>> where first column is PID of linpack benchmark and other
>> columns is CPU on which the process was running with
>> granularity of 1 second
>>
>> I would like to check the possibilities to visualize the
>> results to the output similar to lstopo --top (see the
>> attachment). I would like to write a simple utility which will
>> * parse the above file
>> * foreach timestep create an output similar to lstopo --top
>> output showing, where each job was running
>>
>> How difficult would be this? Could you please provide some
>> hints what API functionality to use?
>>
>> Thanks!
>> Jirka
>>
>>
>
>