Re: [sugar] Moving to metacity with composition (was: Preparing for the feature freeze)
For composition to not eat memory (a full frame buffer's worth/activity), the buried windows need to be unmapped in X parlance. When a window is unmapped, X can free the contents of the window even when composite is running (IIRC). This may require some work in whatever window manager we decide on. - Jim Just for the record, I'm not strongly advocating for composition in 8.2. I just happen to think that it could bring a lot of value and we should consider carefully if it's doable or not. -- Jim Gettys [EMAIL PROTECTED] One Laptop Per Child ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Moving to metacity with composition (was: Preparing for the feature freeze)
On Tue, Jun 3, 2008 at 5:09 PM, Martin Dengler [EMAIL PROTECTED] wrote: As an aside... On Tue, Jun 03, 2008 at 12:16:27PM +0200, Tomeu Vizoso wrote: Sayamindu, you say you got OOM problems after activating composition, can you check where that memory is going? Or might be the X server crashing instead? Even on my C2 yum search yummemoryimprovesinf9 causes significant memory pressure[1]. Sugar/Glucose/Sweetness becomes unresponsive, though oom-killer doesn't get involved. I'm surprised that it's even feasible to run yum on a B4 with sugar running. I've been using compcache[2,3] to help with this pressure. Cheers, Tomeu Martin 1. As in, free in vmstat goes down to 0, from 40. Yeah, this is imprecise. cache is still fine at 80. joyride-1998. That's not downloading any updates, no activities running. 2. http://dev.laptop.org/ticket/28 3. http://www.xades.com/ , compcache on the XO I tried your ps_mem.py based tests, as outlined at http://lists.laptop.org/pipermail/sugar/2008-March/004718.html (well, not an exact replica, but close to it). I was running os16 from http://pilgrim.laptop.org/~pilgrim/olpc/streams/olpc3/build16/, and was unable to run most activities on it (eg: Web, Write, etc). The before part of the test was done with matchbox (the stock one which came with the os), and the after part with metacity, with compositor enabled. The results are as follows: - before: 2.5 MiB + 459.0 KiB = 2.9 MiBmatchbox-window-manager - after.: 1.8 MiB + 552.5 KiB = 2.3 MiBmetacity - - before: 73.3 MiB + 5.3 MiB = 78.6 MiBpython (12) after.: 73.7 MiB + 5.6 MiB = 79.3 MiBpython (12) - before: 13.1 MiB + 1.9 MiB = 14.9 MiBTerminal 17c20 after.: 13.1 MiB + 1.8 MiB = 14.9 MiBTerminal b9662 - - before: 26.4 MiB + 3.5 MiB = 29.9 MiBMeasure 5f0940 after.: 26.4 MiB + 3.4 MiB = 29.9 MiBMeasure ff6038 - before: 11.9 MiB + 2.0 MiB = 14.0 MiBJournal 01f5e1 after.: 13.0 MiB + 2.0 MiB = 15.0 MiBJournal 8828b9 - before: 6.2 MiB + 514.0 KiB = 6.7 MiBXorg after.: 20.7 MiB + 466.0 KiB = 21.2 MiBXorg Cheers, Sayamindu -- Sayamindu Dasgupta [http://sayamindu.randomink.org/ramblings] ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Moving to metacity with composition (was: Preparing for the feature freeze)
On Wed, Jun 04, 2008 at 09:28:40PM +0530, Sayamindu Dasgupta wrote: I tried your ps_mem.py based tests [...] Cool -- looks like just moving to os16 + metacity saved at least 14 MiB[1] (not counting any python savings) and Xorg grew by 15 MiB. Cheers, Sayamindu Martin 1. 2 + 6 + 6 MiB: matchbox - metacity, Terminal, and Journal MiB savings. These are obviously not numbers to rely on, but they're probably a decent in-kind test (as I saw net memory usage grow, and so did you, but the growths are on the same order of magnitude. As it looks like many other things might have got a lot better, this still seems pretty promising to me. pgpjl0gJua3Jr.pgp Description: PGP signature ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Moving to metacity with composition (was: Preparing for the feature freeze)
On Tue, Jun 3, 2008 at 11:54 AM, Marco Pesenti Gritti [EMAIL PROTECTED] wrote: On Tue, Jun 3, 2008 at 11:45 AM, Tomeu Vizoso [EMAIL PROTECTED] wrote: Priority 2. I would love to have it but it might be too late, given that Sayamindu experimentation run into interesting problems. A nice thing about this is that little changes to sugar are expected to be needed, so it's easy to swap-in swap-out, perhaps in a quick 8.2.1 release? Well, if we go for the fullscreen hint approach, it will need changes to all the non-python activities, so it would be pretty invasive. Ouch, is that acceptable? What will happen when kids try to run an old activity? activate composition (eToys and Record have trouble with this). Priority 1. Can we actually do this given the memory constraints? We'll be saving 3.5MB per python activity with the prefork trick, and in the worst case we would be having a penalty of 2MB per fullscreen window because of composition. Bernando was saying that this is not possible because of *video* memory constraints. Hmm, but not all those pixmaps will be kept in video mem, right? If so, then I don't get why the faster builds work so fine. Anyway, Martin Dengler did an awesome job measuring the mem hit in matchbox, so I guess we should reread it and maybe redo the tests with metacity: http://lists.laptop.org/pipermail/sugar/2008-March/004718.html Sayamindu, you say you got OOM problems after activating composition, can you check where that memory is going? Or might be the X server crashing instead? If we only keep the active activity composited, we could limit this to a total of 4MB with peaks of 6MB (desktop window + active activity + inactive activity while we take the screenshot). I would like to see a proof of concept of this approach. Me too ;) Just for the record, I'm not strongly advocating for composition in 8.2. I just happen to think that it could bring a lot of value and we should consider carefully if it's doable or not. Cheers, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Moving to metacity with composition (was: Preparing for the feature freeze)
On Tue, Jun 3, 2008 at 12:16 PM, Tomeu Vizoso [EMAIL PROTECTED] wrote: On Tue, Jun 3, 2008 at 11:54 AM, Marco Pesenti Gritti [EMAIL PROTECTED] wrote: On Tue, Jun 3, 2008 at 11:45 AM, Tomeu Vizoso [EMAIL PROTECTED] wrote: Priority 2. I would love to have it but it might be too late, given that Sayamindu experimentation run into interesting problems. A nice thing about this is that little changes to sugar are expected to be needed, so it's easy to swap-in swap-out, perhaps in a quick 8.2.1 release? Well, if we go for the fullscreen hint approach, it will need changes to all the non-python activities, so it would be pretty invasive. Ouch, is that acceptable? What will happen when kids try to run an old activity? Well, there is no official API freeze in effect yet. Old activities will get a window frame. Personally I think that's acceptable if using the fullscreen hint is considered the best semantic. We could also consider to use normal window + maximized. If someone could spend some time thinking about the possible approaches and to write them down (with advantages and disadvantages) that would be a good step forward. activate composition (eToys and Record have trouble with this). Priority 1. Can we actually do this given the memory constraints? We'll be saving 3.5MB per python activity with the prefork trick, and in the worst case we would be having a penalty of 2MB per fullscreen window because of composition. Bernando was saying that this is not possible because of *video* memory constraints. Hmm, but not all those pixmaps will be kept in video mem, right? If so, then I don't get why the faster builds work so fine. What I understood from Bernardo is that they needs to be in video mem. If you open several windows in faster and try to rotate the screen, does it work? Marco ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
