Robert Bradshaw wrote:
>
>>> Using procfs is the correct solution. This code needs to be
>>> conditionally embedded in Sage in a similar way to the Darwin code.
>>> Having just done something similar for FreeBSD (still being tested
>>> so no ticket yet), the approach is presumably:
>>>
>>> Create solaris_memory_usage.c, solaris_memory_usage.h and
>>> solaris_utilities.pyx to provide a Python solaris_virtual_size
>>> function that calls the relevant procfs functions.
>>>
>>> Patch sage/ext/gen_interpreters.py to include the above:
>>>
>>> if UNAME[0] == "Solaris":
>>> ext_modules.append(
>>> Extension('sage.misc.solaris_utilities',
>>> sources = ['sage/misc/solaris_memory_usage.c',
>>> 'sage/misc/solaris_utilities.pyx'],
>>> depends = ['sage/misc/solaris_memory_usage.h']
>>> )
>>>
>> Well, I made it more flexible than just memory usage. It can return
>> the
>> load averages for the system as a whole, the amount of physical
>> ram, the
>> number of physical processors, the processor speed ... etc etc. I've
>> tried to make it of more general usage, hoping that it can
>> eventually be
>> used to provide all the information people need post when they ask for
>> support requests. For now it is not complete, but it is sufficiently
>> complete to solve the particular issue.
>>
>> drkir...@smudge:[~] $ ./a.out processor_speed
>> 1200
>> drkir...@smudge:[~] $ ./a.out physical_processors
>> 2
>> drkir...@smudge:[~] $ ./a.out physical_ram_in_MB
>> 8192
>>
>> The next command takes the PID and reports the image size, which is I
>> think what you want.
>>
>> drkir...@smudge:[~] $ ./a.out image_size 27808
>> 309.9
>>
>> drkir...@smudge:[~] $ ./a.out resident_size 27808
>> 243.2
>>
>> $ ./a.out system_load_averages
>> 1-minute = 4.98, 5-minute = 3.02, 15-minute = 2.58
>>
>> drkir...@smudge:[~] $ ./a.out processor_set_load_averages
>> 1-minute = 5.50, 5-minute = 3.29, 15-minute = 2.6
>>
>> I don't need a header file. The code is sufficiently simple to not
>> need
>> one. If there was one, it would only have 6 lines in it, and I think
>> that will just make the code harder to read than putting the 6
>> lines in
>> the C source code.
>>
>> Should my 'solaris_system_information' command be installed in a .spkg
>> of its own, that only gets built on Solaris? Should the command
>> then be
>> installed to $SAGE_HOME/local/bin ?
>>
>> I can write the C code without problem, but I am stuck on exactly
>> how to
>> integrate it into Sage.
>
> Probably belongs in devel/sage/c_lib. Just make them functions that
> return longs (bytes is the most logical unit), and then we can make
> getusage invoke them directly.
I was anticipating making this a stand alone executable to replace
'top', since 'top' is being called that way. (I would tend to agree that
getting information from a library function is probably a better way to
do this, but I don't know enough python to do all this.)
At the moment 'make test' is bringing my Solaris box to an almost
standstill, as 'top' is being called thousands of times per second.
Note also the code at present in Sage assumes the data will be in MB,
which is what 'top' usually reports. I'm not 100% sure that would be so
with very small or very large processes. Certainly Sun's 'prstat'
changes between kB and MB, and perhaps even GB (can't say I have tested
that).
If my code returns things like load averages, then clearly in that case
it will need to return an array of floating point numbers, not a 'long'.
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send an email to [email protected]
To unsubscribe from this group, send an email to
[email protected]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---
