Peter Jeremy wrote:
> On 2009-Aug-24 23:26:26 +0100, "Dr. David Kirkby" <[email protected]> 
> wrote:
>> Yes, I finally found it myself. I like this bit of code:
> [devel/sage-main/sage/misc/getusage.py extract removed]
> 
> I'm glad someone liked it - it made me feel somewhat ill :-)
> 
>> It would appear to me the code is attempting to read the 5th column of 
>> 'top' which is marked 'SIZE'. I'm not sure if that is a very useful 
>> thing to get, as the number returned includes that memory that is shared 
>> with other processes.
> 
> It's intended to emulate the VmSize value in Linux's /proc/<pid>/status -
> which is the process's virtual size.
> 
>> I would have thought the 6th column, which is the 
>> memory used by that process alone (i.e. resident size) was more useful. 
> 
> Not really.  RSS just measures the amount of physical memory currently
> occupied by the process.  AFAIK, it also includes shared memory.  And
> the main use I can see for get_memory_usage is to check for memory
> leaks - which are more obvious in VSZ than RSS.  Including shared memory
> is irrelevant for this because it won't change.  OTOH, leaked memory is
> not used and therefore likely to be paged out and so not counted in RSS.

Any sensible attempt to use the memory usage figure for finding memory 
leaks is going to need this done to a resolution of 1 byte, not 1 MB.

>> The following bit of C code finds the memory used by process 1877 (I 
>> have hard-coded that for now, but I'll change it later). It reports data 
>> in bytes.
> 
> 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.

I do need to resolve one issue though. Apparently on SPARC, it is 
possible to have different processors running at different speeds. I'm 
not sure whether to report just the mean CPU speed, or perhaps min, mean 
& max. I think for 99% of systems they will all be the same.

I could see the code could be expanded somewhat over time, but for now 
at least, it gets the information we need without calling 'top' which is 
not installed on Solaris by default. (prstat is Sun's tool for this).

Dave





--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to