On Aug 26, 2009, at 3:32 PM, Dr. David Kirkby wrote: > > 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.
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 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 think any of the above, with a comment, should be sufficient for our purposes. -Robert --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
