Re: cairo has now 16bit surfaces (was Fwd: rendering-cleanup)
On Sat, Aug 7, 2010 at 02:20, Bernie Innocenti ber...@codewiz.org wrote: El Tue, 03-08-2010 a las 16:26 +0200, Tomeu Vizoso escribió: This means that graphic operations would be considerably faster on the XO-1 because to date we are rendering to 24bit surfaces that the X server has to convert to 16bit every time. Fantastic news! In order to benefit in Sugar, do you think we'd have to wait until 16bit surface support is propagated to GTK, libsrvg, hippocanvas, etc? I'd expect well-written code to call cairo_surface_create_similar() whenever possible, but there might be hot-spots in our software stack that assume 32bpp. Have given a look to gtk+ and the xlib backend of cairo and seems to me that we are safe. We just need Maltose to come quickly to XO-1 :) Regards, Tomeu -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: MicroSD Card performance variance on XO-1.5
On Sat, Aug 7, 2010 at 02:52, Bernie Innocenti ber...@codewiz.org wrote: El Fri, 06-08-2010 a las 18:50 +0200, Tomeu Vizoso escribió: I also think our vm.dirty_* settings are wrong and likely causing our current fill-buffer-and-stutter behaviour. We are using the defaults and those are for spinning harddrives, with a significant cost to spinning up the disk on a laptop -- hence long expire_centisecs and writeback_centisecs and the assumption that once you've started writing, it'll be written out fast. We have zero seek costs, zero spin disk up costs, but slowish writes -- we have to start writing buffers out ASAP. I had also had the impression for some time that some knobs in the kernel could have been better tuned for the XO-1 and the actual workload. That was also my gut feeling. Swappiness also seems to be set too high. We should probably let the OOM killer kick in before the machine becomes totally unresponsive. Btw, have read that some notifications about available memory have landed in cgroups in recent kernels. The Sugar shell could listen to those and give a chance to background activities to save their state before killing them, thus avoiding OOM in some (most?) cases. Regards, Tomeu Tuning the VM knobs is no joke. We could proceed by applying some reasonable changes early in the next development cycle, then sit back and wait for users to tell us their overall impression of using the system as usual. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: MicroSD Card performance variance on XO-1.5
[cc += sugar-devel, tch] El Sat, 07-08-2010 a las 11:27 +0200, Tomeu Vizoso escribió: Btw, have read that some notifications about available memory have landed in cgroups in recent kernels. The Sugar shell could listen to those and give a chance to background activities to save their state before killing them, thus avoiding OOM in some (most?) cases. We could do this even without an advanced reporting mechanism. The monitoring code in the CPU Memory meter could detect memory shortage and automatically quit the least recently used activity. Or, maybe, we could make this a manual process: pop up a notification when memory is short and ask which activity should be closed. A while ago, Tincho has been working on implementing the Freedesktop notification protocol in Sugar. This feature didn't make it for Dextrose, but perhaps it could be completed in time to be merged into 0.90. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: cairo has now 16bit surfaces (was Fwd: rendering-cleanup)
El Sat, 07-08-2010 a las 11:25 +0200, Tomeu Vizoso escribió: I'd expect well-written code to call cairo_surface_create_similar() whenever possible, but there might be hot-spots in our software stack that assume 32bpp. Have given a look to gtk+ and the xlib backend of cairo and seems to me that we are safe. We just need Maltose to come quickly to XO-1 :) ... or backport the new cairo to Fedora 11. The Cairo ABI is supposed to be 100% backwards compatible, and I've successfully rebuilt 1.8 with no issues. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: MicroSD Card performance variance on XO-1.5
On Sat, Aug 7, 2010 at 18:11, Bernie Innocenti ber...@codewiz.org wrote: [cc += sugar-devel, tch] El Sat, 07-08-2010 a las 11:27 +0200, Tomeu Vizoso escribió: Btw, have read that some notifications about available memory have landed in cgroups in recent kernels. The Sugar shell could listen to those and give a chance to background activities to save their state before killing them, thus avoiding OOM in some (most?) cases. We could do this even without an advanced reporting mechanism. The monitoring code in the CPU Memory meter could detect memory shortage and automatically quit the least recently used activity. So we would have a periodic wakeup? The test would be the amount of free memory plus buffers and caches? Or, maybe, we could make this a manual process: pop up a notification when memory is short and ask which activity should be closed. I would just close one of the background activities, the LRU or the biggest one. Regards, Tomeu A while ago, Tincho has been working on implementing the Freedesktop notification protocol in Sugar. This feature didn't make it for Dextrose, but perhaps it could be completed in time to be merged into 0.90. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: cairo has now 16bit surfaces (was Fwd: rendering-cleanup)
On Sat, Aug 7, 2010 at 18:14, Bernie Innocenti ber...@codewiz.org wrote: El Sat, 07-08-2010 a las 11:25 +0200, Tomeu Vizoso escribió: I'd expect well-written code to call cairo_surface_create_similar() whenever possible, but there might be hot-spots in our software stack that assume 32bpp. Have given a look to gtk+ and the xlib backend of cairo and seems to me that we are safe. We just need Maltose to come quickly to XO-1 :) ... or backport the new cairo to Fedora 11. The Cairo ABI is supposed to be 100% backwards compatible, and I've successfully rebuilt 1.8 with no issues. Sounds good, if that gives problems we can consider backporting just that patch. If the small patch below is really what was needed, I'm going to feel quite stupid: http://cgit.freedesktop.org/cairo/commit/?id=022291be1cbddf4f6722f0bf76ebda6922780276 Regards, Tomeu -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Killing activities when memory gets short
El Sat, 07-08-2010 a las 18:14 +0200, Tomeu Vizoso escribió: So we would have a periodic wakeup? The test would be the amount of free memory plus buffers and caches? A polled design is clearly inferior to a proper notification system, but it has the advantage of being simple and not requiring a particular kernel. Once this is done, switching to a better solution should not require extensive changes to the UI code. BTW, looking at top, it seems that Sugar and other processes wake up quite frequently when the system is supposed to be completely idle. It may be background checks for updates, NetworkManager updates or the presence service. Plus, there are a bunch of cron jobs that run in the background, inclding the ds-backup and olpc-update. All these things drain battery power and cause the UI to become jerky, so we should try to limit them if possible. Or, maybe, we could make this a manual process: pop up a notification when memory is short and ask which activity should be closed. I would just close one of the background activities, the LRU or the biggest one. +1. This, however, makes non-sugarized activities more dangerous to deal with. One more reason to demand proper sugarization. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Killing activities when memory gets short
On Sat, Aug 7, 2010 at 19:31, Bernie Innocenti ber...@codewiz.org wrote: El Sat, 07-08-2010 a las 18:14 +0200, Tomeu Vizoso escribió: So we would have a periodic wakeup? The test would be the amount of free memory plus buffers and caches? A polled design is clearly inferior to a proper notification system, but it has the advantage of being simple and not requiring a particular kernel. Once this is done, switching to a better solution should not require extensive changes to the UI code. BTW, looking at top, it seems that Sugar and other processes wake up quite frequently when the system is supposed to be completely idle. It may be background checks for updates, NetworkManager updates or the presence service. Plus, there are a bunch of cron jobs that run in the background, inclding the ds-backup and olpc-update. All these things drain battery power and cause the UI to become jerky, so we should try to limit them if possible. NM is particularly active when there are more than a few APs available, wonder if it would be possible to tune it to group updates in batches. Regards, Tomeu Or, maybe, we could make this a manual process: pop up a notification when memory is short and ask which activity should be closed. I would just close one of the background activities, the LRU or the biggest one. +1. This, however, makes non-sugarized activities more dangerous to deal with. One more reason to demand proper sugarization. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: cairo has now 16bit surfaces (was Fwd: rendering-cleanup)
El Sat, 07-08-2010 a las 18:19 +0200, Tomeu Vizoso escribió: Sounds good, if that gives problems we can consider backporting just that patch. If the small patch below is really what was needed, I'm going to feel quite stupid: http://cgit.freedesktop.org/cairo/commit/?id=022291be1cbddf4f6722f0bf76ebda6922780276 Wait, that can't be everything. Where are all the software operations to work on RGB16_565 surfaces and convert them to/from other formats?!? Wait, I think I know: all the hard code is implemented in pixman. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Killing activities when memory gets short
On Sat, Aug 7, 2010 at 19:33, Tomeu Vizoso to...@sugarlabs.org wrote: On Sat, Aug 7, 2010 at 19:31, Bernie Innocenti ber...@codewiz.org wrote: El Sat, 07-08-2010 a las 18:14 +0200, Tomeu Vizoso escribió: So we would have a periodic wakeup? The test would be the amount of free memory plus buffers and caches? A polled design is clearly inferior to a proper notification system, but it has the advantage of being simple and not requiring a particular kernel. Once this is done, switching to a better solution should not require extensive changes to the UI code. BTW, looking at top, it seems that Sugar and other processes wake up quite frequently when the system is supposed to be completely idle. It may be background checks for updates, NetworkManager updates or the presence service. Plus, there are a bunch of cron jobs that run in the background, inclding the ds-backup and olpc-update. All these things drain battery power and cause the UI to become jerky, so we should try to limit them if possible. NM is particularly active when there are more than a few APs available, wonder if it would be possible to tune it to group updates in batches. On a second thought, Sugar should probably only listen to events relevants to what is being currently displayed. This would display outdated data for a short while and would mean significant rework but may be a worthy goal for the future. Regards, Tomeu Regards, Tomeu Or, maybe, we could make this a manual process: pop up a notification when memory is short and ask which activity should be closed. I would just close one of the background activities, the LRU or the biggest one. +1. This, however, makes non-sugarized activities more dangerous to deal with. One more reason to demand proper sugarization. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Killing activities when memory gets short
El Sat, 07-08-2010 a las 19:33 +0200, Tomeu Vizoso escribió: BTW, looking at top, it seems that Sugar and other processes wake up quite frequently when the system is supposed to be completely idle. It may be background checks for updates, NetworkManager updates or the presence service. Plus, there are a bunch of cron jobs that run in the background, inclding the ds-backup and olpc-update. All these things drain battery power and cause the UI to become jerky, so we should try to limit them if possible. NM is particularly active when there are more than a few APs available, wonder if it would be possible to tune it to group updates in batches. That would be a good question for Dan (cc'd :-). -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Lazy Network Neighborhood updates
El Sat, 07-08-2010 a las 19:36 +0200, Tomeu Vizoso escribió: On a second thought, Sugar should probably only listen to events relevants to what is being currently displayed. This would display outdated data for a short while and would mean significant rework but may be a worthy goal for the future. We already readjust the network neighborhood layout on the fly when we switch view. It's funny to see the access points slide around :-) So, +1 for lazy updates, as long as NM keeps doing its background scanning even when it's not being queried by the client. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Killing activities when memory gets short
Hi all, On Sat, Aug 7, 2010 at 6:31 PM, Bernie Innocenti ber...@codewiz.org wrote: El Sat, 07-08-2010 a las 18:14 +0200, Tomeu Vizoso escribió: So we would have a periodic wakeup? The test would be the amount of free memory plus buffers and caches? A polled design is clearly inferior to a proper notification system, but it has the advantage of being simple and not requiring a particular kernel. Once this is done, switching to a better solution should not require extensive changes to the UI code. BTW, looking at top, it seems that Sugar and other processes wake up quite frequently when the system is supposed to be completely idle. It may be background checks for updates, NetworkManager updates or the presence service. Plus, there are a bunch of cron jobs that run in the background, inclding the ds-backup and olpc-update. All these things drain battery power and cause the UI to become jerky, so we should try to limit them if possible. Or, maybe, we could make this a manual process: pop up a notification when memory is short and ask which activity should be closed. I would just close one of the background activities, the LRU or the biggest one. +1. Just killing a random activity is a terrible idea becayse you don't want your product behaving like it's defective; the pop up idea is way more acceptable(and a lot better than having the system randomly behaving like it's crashed). Either way, this is the extremely important use of swap memory that doesn't exist here. I understand your engineering constraints on the hardware but randomly killing activities is poised to confuse users and cause people considering the hardware for deployment to think that you're selling them something defective/baddly manufactured. Best regards, Tiago Marques This, however, makes non-sugarized activities more dangerous to deal with. One more reason to demand proper sugarization. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Lazy Network Neighborhood updates
Hi Mikus, On 7 Aug 2010, at 20:01, Mikus Grinbergs mi...@bga.com wrote: We already readjust the network neighborhood layout on the fly when we switch view. It's funny to see the access points slide around :-) Haven't bothered to keep track of the appearance/disappearance of XO and AP icons in Neighborhood View - it's hard to figure out whether their presence on screen is determined by View updating or by radio reception. But something that needs attention is the handling of invitation icons in Neighborhood view. I would like such an icon to mean there exists RIGHT NOW someone else with whom I can collaborate. Instead, these icons seem to persist long after all invitors/invitees are gone. Nice observation. I'm afraid I seem to rarely use invitations when testing, though I do test Journal file transfers a reasonable amount — which falls into a similar situation. So is this as 'simple' as removing the notification when the activity id is no longer being shared? Or would you like the UI to still indicate that you had missed the event/s? --Gary Thanks, mikus ___ Sugar-devel mailing list sugar-de...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Lazy Network Neighborhood updates
invitation icons seem to persist long after all invitors/invitees are gone. is this as 'simple' as removing the notification when the activity id is no longer being shared? Or would you like the UI to still indicate that you had missed the event/s? I imagine if someone clicks on an invitation, sees his Activity being launched, but then fails to make a connection -- that could well be more frustrating than never seeing evidence of the event/s having happened. mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Killing activities when memory gets short
On Sat, Aug 7, 2010 at 1:31 PM, Bernie Innocenti ber...@codewiz.org wrote: El Sat, 07-08-2010 a las 18:14 +0200, Tomeu Vizoso escribió: So we would have a periodic wakeup? The test would be the amount of free memory plus buffers and caches? A polled design is clearly inferior to a proper notification system, but I think we can just win big time without polling and without killing. - grab the python code from ps_mem.py. We' ll be reading mem usage from our own processes (w/o rainbow at least) so I suspect no need for priv operation - when the user opens a new activity, poll used/free memory with some pre-set constants and if warranted send a 'close' signal to the best candidate (weighed LRU + mem usage score) -- depends on closing without asking for a document name... - Opportunistic checks on activity switch, view change can complement this. The above matches what my Android phone does and as a user, works great. cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
[Server-devel] Exporting Moodle config from XS
Is it possible to export the Moodle configuration from the XS and then install it on another server intended for another site? Obviously the user data is not important in this instance. However the second example would be backing it up, when user data is important. David Leeming ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
