Re: [Fwd: memory usage script]
Jim Gettys wrote: > As many/most of you should know, the Linux/UNIX "ps" command is > *EXTREMELY* misleading on accounting for *ACTUAL* ram in use by a > process. For example, it does not account for register windows being > used by the X server, nor sharing among processes that use the same > shared library. > > Attached is a note from Tridge, pointing to a script that does a much > better job accounting to real usage. > > Note that the Linux kernel has recently started doing a better job > accounting for memory usage as well (after 2.6.23-rc8-mm1). >- Jim > > [EMAIL PROTECTED] > Date: Tue, 17 Jun 2008 07:39:51 +1000 > > Here is a link: > > http://www.pixelbeat.org/scripts/ps_mem.py Cool. I'm the author of that script. If you have any changes you would like just yell. Pádraig. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Performance tuning for the XO
C. Scott Ananian wrote: > We make currently make heavy use of hashing in our upgrade & > verification infrastructure. I'd like to find the fastest possible > implementation of the SHA-256 and/or RIPEMD-160 algorithms. Can > anyone offer me advice on the proper compilation options and > strategies for maximum performance on the processor in the XO? I > don't see the -mxo option to gcc yet. > --scott I've no hardware currently to test with unfortunately. Some links that may be of interest though: http://lists.laptop.org/pipermail/devel/2006-September/002415.html http://dev.laptop.org/git?p=geode-perf;a=summary http://www.lysator.liu.se/~nisse/nettle/ http://www.pixelbeat.org/scripts/gcccpuopt ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: PSS/USS (Was: The "iGoogle bug")
Bernardo Innocenti wrote: > Pádraig Brady wrote: > >>> This gives even better results: >>> >>> http://lwn.net/Articles/230975/ >>> http://www.linuxworld.com/news/2007/042407-kernel.html >>> >>> The PSS and USS are are the Right Thing: they give users and >>> developers a honest and accurate figure. >>> >>> The downside is that it would require a very fresh kernel or 13 >>> invasive VM patches. >>> >> I've just updated my ps_mem.py tool to use PSS when available: >> http://www.pixelbeat.org/scripts/ps_mem.py > > Cool! > > But I don't see the PSS support in 2.6.23, and the patchset originally > posted on the lkml is stale. > > Where does up-to-date kernel support for PSS live? Oops sorry. I saw the patch here and assumed it was going into 2.6.23: http://lkml.org/lkml/2007/8/16/306 It would be great to get this in ASAP, as it's a trivial but very useful extension to smaps cheers, Pádraig. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: The "iGoogle bug"
Bernardo Innocenti wrote: > Jim Gettys wrote: > > >> Don't confuse virtual address space used with RAM consumed: most of that >> is shared memory (glibc, pango, gtk+). >> >> That's why memphis was written and is in our build: ps gives very >> misleading memory usage statistics, unless you really understand what it >> is reporting. It does a bit better job accounting for memory used in a >> mere-mortal way to understand. > > This gives even better results: > > http://lwn.net/Articles/230975/ > http://www.linuxworld.com/news/2007/042407-kernel.html > > The PSS and USS are are the Right Thing: they give users and > developers a honest and accurate figure. > > The downside is that it would require a very fresh kernel or 13 > invasive VM patches. > I've just updated my ps_mem.py tool to use PSS when available: http://www.pixelbeat.org/scripts/ps_mem.py cheers, Pádraig. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: The "iGoogle bug"
Jim Gettys wrote: > Bert, > > Don't confuse virtual address space used with RAM consumed: most of that > is shared memory (glibc, pango, gtk+). > > That's why memphis was written and is in our build: ps gives very > misleading memory usage statistics, unless you really understand what it > is reporting. It does a bit better job accounting for memory used in a > mere-mortal way to understand. cool http://dev.laptop.org/git?p=projects/memphis;a=tree > > Even so, right now we'll find lots more RAM consumed that we'd like, due > to how python loads modules; we have schemes for fixing this using fork > and copy on write. See also http://www.pixelbeat.org/scripts/ps_mem.py cheers, Pádraig. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Inflation
Bernardo Innocenti wrote: > Build JFFS2 size > - > 465183MB > 466203MB > 478203MB > 482205MB I just ran fslint¹ on build 485² and it reported³: 14,077,952 bytes wasted in 1590 files (in 1495 groups) due to duplicate files. For example there are many duplicate py[oc] files, and /usr/share/activities/TamTam.activity/Resources/Sounds/lab[1-6] all contain the same data (wasting 600K alone). cheers, Pádraig. ¹ http://www.pixelbeat.org/fslint/ ² http://olpc.download.redhat.com/olpc/streams/development/LATEST/devel_ext3/olpc-redhat-stream-development-build-485-20070703_0249-devel_ext3-tree.tar.bz2 ³ http://www.pixelbeat.org/fslint/olpc_build_485.dupes ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Pagemap
Jordan Crouse wrote: > They just talked about pagemap from Matt Mackall during an BoF at OLS. > This seems like something useful we can use to measure our memory > usage - in particular, it is screaming for tinderbox integration.. :) > > http://lkml.org/lkml/2007/4/3/405 > > (patches are in -mm - map2*). A related python tool, using the older smaps interface is: http://www.pixelbeat.org/scripts/ps_mem.py cheers, Pádraig. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
