Re: For all ya BFS (brain fuck scheduler) lovers out there
On 9/18/09, Warren Baird wrote: > On Wed, Sep 16, 2009 at 3:11 PM, George Brooke > wrote: > >> >> Could you do a battery life test with the NO_NEW_FAIR_SLEEPERS option >> enabled? >> >> > I'm afraid I probably won't have the time to run a test like that... I > agree that it would be interesting if someone does, though. > > Warren How it could have any influence on battery time? :x It has very little difference on speed of apps, I really wouldn't expect anything from battery. -- Sebastian Krzyszkowiak dos ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: For all ya BFS (brain fuck scheduler) lovers out there
On Wed, Sep 16, 2009 at 3:11 PM, George Brooke wrote: > > Could you do a battery life test with the NO_NEW_FAIR_SLEEPERS option > enabled? > > I'm afraid I probably won't have the time to run a test like that... I agree that it would be interesting if someone does, though. Warren -- Warren Baird - Photographer and Digital Artist http://www.synergisticimages.ca ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: For all ya BFS (brain fuck scheduler) lovers out there
I've tested the option with an old SHR-U Image from 8.8.2009 (updated to current) and it feels like... wow, fast. But, after activate option on an other SHR-U there where no improvements to feel. therefore i reflashed my own with the newest image (ca. 6.9.2008) and update it to current state of shr-u. the effect is, when i activate no_new_fair_sleepers, nothing. i feel no more improvements. some tests with the loadspeed of shr-settings shows me, there are no load speed improvements with or without this option. what the fault here? no idear where to search. secondary i found that /proc/sys/kernel/sched_features. when cat this i get 24190 (no_new_fair_sleepers) and 24191 (new_fair_sleepers). does it make sense to set this file to activate the no_new_fair_sleepers instead using the (additional) mounted debugfs? Carci Am Mittwoch, den 16.09.2009, 20:11 +0100 schrieb George Brooke: > On Wednesday 16 September 2009 18:03:48 Warren Baird wrote: > > > WTF? How swapping windows can take 15 seconds? Here it's immediately, > > > with sometimes max ~1 second lag! > > > > I was swapping through all visible screens twice - waiting for the redraw > > each time - I was probably doing 14 or 16 window swaps total - so it went > > from around 1s/swap to about .66 s/swap... > > > > Warren > Could you do a battery life test with the NO_NEW_FAIR_SLEEPERS option enabled? > > solar.george > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: For all ya BFS (brain fuck scheduler) lovers out there
like... wow, fast. But, after activate option on an other SHR-U there where no improvements to feel. therefore i reflashed my own with the newest image (ca. 6.9.2008) and update it to current state of shr-u. the effect is, when i activate no_new_fair_sleepers, nothing. i feel no more improvements. some tests with the loadspeed of shr-settings shows me, there are no load speed improvements with or without this option. what the fault here? no idear where to search. secondary i found that /proc/sys/kernel/sched_features. when cat this i get 24190 (no_new_fair_sleepers) and 24191 (new_fair_sleepers). does it make sense to set this file to activate the no_new_fair_sleepers instead using the (additional) mounted debugfs? Carci (sorry about douplicate,nabble did not send message) Am Mittwoch, den 16.09.2009, 20:11 +0100 schrieb George Brooke: > On Wednesday 16 September 2009 18:03:48 Warren Baird wrote: > > > WTF? How swapping windows can take 15 seconds? Here it's immediately, > > > with sometimes max ~1 second lag! > > > > I was swapping through all visible screens twice - waiting for the redraw > > each time - I was probably doing 14 or 16 window swaps total - so it went > > from around 1s/swap to about .66 s/swap... > > > > Warren > Could you do a battery life test with the NO_NEW_FAIR_SLEEPERS option enabled? > > solar.george > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: For all ya BFS (brain fuck scheduler) lovers out there
On Wednesday 16 September 2009 18:03:48 Warren Baird wrote: > > WTF? How swapping windows can take 15 seconds? Here it's immediately, > > with sometimes max ~1 second lag! > > I was swapping through all visible screens twice - waiting for the redraw > each time - I was probably doing 14 or 16 window swaps total - so it went > from around 1s/swap to about .66 s/swap... > > Warren Could you do a battery life test with the NO_NEW_FAIR_SLEEPERS option enabled? solar.george signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: For all ya BFS (brain fuck scheduler) lovers out there
> WTF? How swapping windows can take 15 seconds? Here it's immediately, > with sometimes max ~1 second lag! > I was swapping through all visible screens twice - waiting for the redraw each time - I was probably doing 14 or 16 window swaps total - so it went from around 1s/swap to about .66 s/swap... Warren -- Warren Baird - Photographer and Digital Artist http://www.synergisticimages.ca ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: For all ya BFS (brain fuck scheduler) lovers out there
On 9/16/09, Warren Baird wrote: > I decided to try a semi-formal experiment... I haven't had time to do > multiple repetitions but I figured I'd share anyways. I'm running shr-u > updated about a week ago. My process was that I rebooted my FR, ran > through a set of steps, at each point timing how long it took from starting > the action (clicking on the icon, eg) to when the screen was finished > redrawing. > > I ran through two processes I do regularly - start GPS, start up claws mail, > and open my inbox, and then the second was to open the messages program. I > then rebooted and did the entire process again, with the only difference > being that I started up the terminal, added 'NO_NEW_FAIR_SLEEPERS' to the > scheduler, closed the terminal, and repeated the process. At the end of > each process I used the illume 'next window' arrow to flip through all the > open windows twice - 5 separate windows - waiting for a full redraw before > proceeding, > > starting claws-mail was noticable faster - 18s vs. 23s (about 20% faster), > and opening the inbox was also faster 14s vs 18s. Unfortunately the SHR > settings panel and SHR messages were about the same.Swapping windows was > also a lot quicker - 15s vs. 10s. > > It'd be good if we had more info - but based on this, it definitely looks > like a win to leave enabled. > > Warren WTF? How swapping windows can take 15 seconds? Here it's immediately, with sometimes max ~1 second lag! -- Sebastian Krzyszkowiak dos ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: For all ya BFS (brain fuck scheduler) lovers out there
I decided to try a semi-formal experiment... I haven't had time to do multiple repetitions but I figured I'd share anyways. I'm running shr-u updated about a week ago. My process was that I rebooted my FR, ran through a set of steps, at each point timing how long it took from starting the action (clicking on the icon, eg) to when the screen was finished redrawing. I ran through two processes I do regularly - start GPS, start up claws mail, and open my inbox, and then the second was to open the messages program. I then rebooted and did the entire process again, with the only difference being that I started up the terminal, added 'NO_NEW_FAIR_SLEEPERS' to the scheduler, closed the terminal, and repeated the process. At the end of each process I used the illume 'next window' arrow to flip through all the open windows twice - 5 separate windows - waiting for a full redraw before proceeding, starting claws-mail was noticable faster - 18s vs. 23s (about 20% faster), and opening the inbox was also faster 14s vs 18s. Unfortunately the SHR settings panel and SHR messages were about the same.Swapping windows was also a lot quicker - 15s vs. 10s. It'd be good if we had more info - but based on this, it definitely looks like a win to leave enabled. Warren On Mon, Sep 14, 2009 at 10:43 AM, Rui Miguel Silva Seabra wrote: > On Mon, Sep 14, 2009 at 03:26:20PM +0100, Rui Miguel Silva Seabra wrote: > > On Mon, Sep 14, 2009 at 01:51:44PM +0400, Paul Fertser wrote: > > > Thanks to LKML discussion there's an interesting switch found that > > > reportedly makes CFS behave as good as BFS for typical desktop > workloads. > > > > > > Read all the details at [1] and to try it on your devices, simply do: > > > > > > mkdir /debug > > > mount -t debugfs none /debug > > > echo NO_NEW_FAIR_SLEEPERS > /debug/sched_features > > > > > > It will magically solve all the problems but i hope it can improve > > > experience at least somewhat. > > > > > > [1] http://marc.info/?l=linux-kernel&m=125260838709566&w=3 > > > > I will keep it on for some more time, but I must say that the effect > > was immediate. This is what I did try immediately and already felt a > > difference: > > > > 1) expand panel (faster) > > 2) get task list (faster) > > 3) switch applications from task list (faster) > > 4) switch applications from panel left and right buttons (faster) > > 5) suspend (faster) > > 6) resume (faster) > > > > Of course I have no idea on the effects of power saving or how much > > of these faster things don't actually suffer from some psychological > > effect :) > > 7) loading SHR's Dialer (faster) >8) time between pressing 'call' and call actually being made (faster) > > Rui > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > -- Warren Baird - Photographer and Digital Artist http://www.synergisticimages.ca ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: For all ya BFS (brain fuck scheduler) lovers out there
On Wed, Sep 16, 2009 at 11:31:05AM +0200, arne anka wrote: > > every reboot? > > i'd say yes. > since debugfs is in memory it will be lost when shutting down. > as pointed out already (by paul iirc), you need to insert the mount into > fstab (and remember, there's a sensible mountpoint already below /sys/ > somewhere, check this thread) and do the echoing in a strupt script > (rc.local springs to mind, since it is there for exactly this kind of > things). It was I. Attention, I'm not sure if /sys/kernel/debug/ is the proper place. Intuitively I'd say yes, but until I know for sure, I'm placing it at some place where it won't cause a conflict (like /debug ) Rui ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: For all ya BFS (brain fuck scheduler) lovers out there
On Wed, 2009-09-16 at 21:21 +1200, Robin Paulson wrote: > 2009/9/14 Paul Fertser : > > Read all the details at [1] and to try it on your devices, simply do: > > > > mkdir /debug > > mount -t debugfs none /debug > > echo NO_NEW_FAIR_SLEEPERS > /debug/sched_features > > how often, if at all, will this get returned to the default value? > > every reboot? > > every upgrade of kernel? > > of some module? > > when i do a cat, it returns this: > > NEW_FAIR_SLEEPERS NORMALIZED_SLEEPER WAKEUP_PREEMPT START_DEBIT > AFFINE_WAKEUPS CACHE_HOT_BUDDY SYNC_WAKEUPS NO_HRTICK NO_DOUBLE_TICK > ASYM_GRAN LB_BIAS LB_WAKEUP_UPDATE ASYM_EFF_LOAD NO_WAKEUP_OVERLAP > LAST_BUDDY > > has it been overwritten already, by a reboot? it looks like it has > > cheers > debugfs is a virtual filesystem that gives access to some otherwise unavailable system bits and pieces. Because its "virtual", its going to dissappear when the FR is rebooted, and "may" even be reset when you unmount debugfs (have not tested this yet). debugfs is also a developers tool, not a normal user tool - google will help you understand whats happening. BillK ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: For all ya BFS (brain fuck scheduler) lovers out there
> every reboot? i'd say yes. since debugfs is in memory it will be lost when shutting down. as pointed out already (by paul iirc), you need to insert the mount into fstab (and remember, there's a sensible mountpoint already below /sys/ somewhere, check this thread) and do the echoing in a strupt script (rc.local springs to mind, since it is there for exactly this kind of things). ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: For all ya BFS (brain fuck scheduler) lovers out there
On Wed, Sep 16, 2009 at 09:21:10PM +1200, Robin Paulson wrote: > 2009/9/14 Paul Fertser : > > Read all the details at [1] and to try it on your devices, simply do: > > > > mkdir /debug > > mount -t debugfs none /debug > > echo NO_NEW_FAIR_SLEEPERS > /debug/sched_features > > how often, if at all, will this get returned to the default value? > > every reboot? Yes. > has it been overwritten already, by a reboot? it looks like it has I added the following to /etc/fstab: debug /debug debugfs auto Then I added a script to activate it as soon as possible: r...@om-gta02 ~ $ cat /etc/rc5.d/S02debugfs #! /bin/sh # -*- coding: utf-8 -*- if [ -f /debug/sched_features ] ; then echo NO_NEW_FAIR_SLEEPERS > /debug/sched_features fi So now I have: r...@om-gta02 ~ $ cat /debug/sched_features NO_NEW_FAIR_SLEEPERS NORMALIZED_SLEEPER WAKEUP_PREEMPT START_DEBIT AFFINE_WAKEUPS CACHE_HOT_BUDDY SYNC_WAKEUPS NO_HRTICK NO_DOUBLE_TICK ASYM_GRAN LB_BIAS LB_WAKEUP_UPDATE ASYM_EFF_LOAD NO_WAKEUP_OVERLAP LAST_BUDDY Rui ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: For all ya BFS (brain fuck scheduler) lovers out there
2009/9/14 Paul Fertser : > Read all the details at [1] and to try it on your devices, simply do: > > mkdir /debug > mount -t debugfs none /debug > echo NO_NEW_FAIR_SLEEPERS > /debug/sched_features how often, if at all, will this get returned to the default value? every reboot? every upgrade of kernel? of some module? when i do a cat, it returns this: NEW_FAIR_SLEEPERS NORMALIZED_SLEEPER WAKEUP_PREEMPT START_DEBIT AFFINE_WAKEUPS CACHE_HOT_BUDDY SYNC_WAKEUPS NO_HRTICK NO_DOUBLE_TICK ASYM_GRAN LB_BIAS LB_WAKEUP_UPDATE ASYM_EFF_LOAD NO_WAKEUP_OVERLAP LAST_BUDDY has it been overwritten already, by a reboot? it looks like it has cheers ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: For all ya BFS (brain fuck scheduler) lovers out there
On Mon, Sep 14, 2009 at 04:32:54PM +0200, Klaus 'mrmoku' Kurzmann wrote: > Am Montag 14 September 2009 15:33:56 schrieb Al Johnson: > > On Monday 14 September 2009, Paul Fertser wrote: > > > Hi, > > > > > > Thanks to LKML discussion there's an interesting switch found that > > > reportedly makes CFS behave as good as BFS for typical desktop workloads. > > > > > > Read all the details at [1] and to try it on your devices, simply do: > > > > > > mkdir /debug > > > mount -t debugfs none /debug > > > echo NO_NEW_FAIR_SLEEPERS > /debug/sched_features > > > > > > It will magically solve all the problems but i hope it can improve > > > experience at least somewhat. > > > > > > [1] http://marc.info/?l=linux-kernel&m=125260838709566&w=3 > > > > According to a later post[2] the mounting should be unnecessary, and this > > should be sufficient: > > > > echo NO_NEW_FAIR_SLEEPERS > /sys/kernel/debug/sched_features > you have to mount debugfs to /sys/kernel/debug then though... as otherwise > /sys/kernel/debug is empty. Probably the idea is that you should rather do: mount -t debugfs none /sys/kernel/debug Rui ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: For all ya BFS (brain fuck scheduler) lovers out there
On Mon, Sep 14, 2009 at 03:26:20PM +0100, Rui Miguel Silva Seabra wrote: > On Mon, Sep 14, 2009 at 01:51:44PM +0400, Paul Fertser wrote: > > Thanks to LKML discussion there's an interesting switch found that > > reportedly makes CFS behave as good as BFS for typical desktop workloads. > > > > Read all the details at [1] and to try it on your devices, simply do: > > > > mkdir /debug > > mount -t debugfs none /debug > > echo NO_NEW_FAIR_SLEEPERS > /debug/sched_features > > > > It will magically solve all the problems but i hope it can improve > > experience at least somewhat. > > > > [1] http://marc.info/?l=linux-kernel&m=125260838709566&w=3 > > I will keep it on for some more time, but I must say that the effect > was immediate. This is what I did try immediately and already felt a > difference: > > 1) expand panel (faster) > 2) get task list (faster) > 3) switch applications from task list (faster) > 4) switch applications from panel left and right buttons (faster) > 5) suspend (faster) > 6) resume (faster) > > Of course I have no idea on the effects of power saving or how much > of these faster things don't actually suffer from some psychological > effect :) 7) loading SHR's Dialer (faster) 8) time between pressing 'call' and call actually being made (faster) Rui ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: For all ya BFS (brain fuck scheduler) lovers out there
Am Montag 14 September 2009 15:33:56 schrieb Al Johnson: > On Monday 14 September 2009, Paul Fertser wrote: > > Hi, > > > > Thanks to LKML discussion there's an interesting switch found that > > reportedly makes CFS behave as good as BFS for typical desktop workloads. > > > > Read all the details at [1] and to try it on your devices, simply do: > > > > mkdir /debug > > mount -t debugfs none /debug > > echo NO_NEW_FAIR_SLEEPERS > /debug/sched_features > > > > It will magically solve all the problems but i hope it can improve > > experience at least somewhat. > > > > [1] http://marc.info/?l=linux-kernel&m=125260838709566&w=3 > > According to a later post[2] the mounting should be unnecessary, and this > should be sufficient: > > echo NO_NEW_FAIR_SLEEPERS > /sys/kernel/debug/sched_features you have to mount debugfs to /sys/kernel/debug then though... as otherwise /sys/kernel/debug is empty. > > [2] http://www.gossamer- > threads.com/lists/linux/kernel/1128181?do=post_view_threaded#1128181 -- Klaus 'mrmoku' Kurzmann ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: For all ya BFS (brain fuck scheduler) lovers out there
On Mon, Sep 14, 2009 at 01:51:44PM +0400, Paul Fertser wrote: > Thanks to LKML discussion there's an interesting switch found that > reportedly makes CFS behave as good as BFS for typical desktop workloads. > > Read all the details at [1] and to try it on your devices, simply do: > > mkdir /debug > mount -t debugfs none /debug > echo NO_NEW_FAIR_SLEEPERS > /debug/sched_features > > It will magically solve all the problems but i hope it can improve > experience at least somewhat. > > [1] http://marc.info/?l=linux-kernel&m=125260838709566&w=3 I will keep it on for some more time, but I must say that the effect was immediate. This is what I did try immediately and already felt a difference: 1) expand panel (faster) 2) get task list (faster) 3) switch applications from task list (faster) 4) switch applications from panel left and right buttons (faster) 5) suspend (faster) 6) resume (faster) Of course I have no idea on the effects of power saving or how much of these faster things don't actually suffer from some psychological effect :) Rui ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: For all ya BFS (brain fuck scheduler) lovers out there
> According to a later post[2] the mounting should be unnecessary, and this > should be sufficient: > > echo NO_NEW_FAIR_SLEEPERS > /sys/kernel/debug/sched_features at least here Linux debian-gta02 2.6.29-20090702.gitd1c828aa #1 PREEMPT Fri Jul 24 22:35:01 UTC 2009 armv4tl GNU/Linux /sys/kernel/debug/sched_features does not exist. -- ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: For all ya BFS (brain fuck scheduler) lovers out there
On Monday 14 September 2009, Paul Fertser wrote: > Hi, > > Thanks to LKML discussion there's an interesting switch found that > reportedly makes CFS behave as good as BFS for typical desktop workloads. > > Read all the details at [1] and to try it on your devices, simply do: > > mkdir /debug > mount -t debugfs none /debug > echo NO_NEW_FAIR_SLEEPERS > /debug/sched_features > > It will magically solve all the problems but i hope it can improve > experience at least somewhat. > > [1] http://marc.info/?l=linux-kernel&m=125260838709566&w=3 According to a later post[2] the mounting should be unnecessary, and this should be sufficient: echo NO_NEW_FAIR_SLEEPERS > /sys/kernel/debug/sched_features [2] http://www.gossamer- threads.com/lists/linux/kernel/1128181?do=post_view_threaded#1128181 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: For all ya BFS (brain fuck scheduler) lovers out there
Niels Heyvaert writes: > Would this setting be changed permanently when following your > instructions below? If not, how can we make it permanent > (ie. applied even after reboot)? Change fstab and stuff the line somewhere in init scripts... -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: For all ya BFS (brain fuck scheduler) lovers out there
On Mon, Sep 14, 2009 at 01:51:44PM +0400, Paul Fertser wrote: >Hi, > >Thanks to LKML discussion there's an interesting switch found that >reportedly makes CFS behave as good as BFS for typical desktop workloads. > >Read all the details at [1] and to try it on your devices, simply do: > >mkdir /debug >mount -t debugfs none /debug >echo NO_NEW_FAIR_SLEEPERS > /debug/sched_features > >It will magically solve all the problems but i hope it can improve >experience at least somewhat. > >[1] http://marc.info/?l=linux-kernel&m=125260838709566&w=3 ITYM "it will not magically solve"? Anyway, it's work-in-progress just as BFS is, and obviously depends on debugfs, and touches tunables BFS doesn't need, and the freerunner is not your typical desktop, so it should be taken with a grain of salt! But thanks :) -- mjt ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: For all ya BFS (brain fuck scheduler) lovers out there
Cool! Would this setting be changed permanently when following your instructions below? If not, how can we make it permanent (ie. applied even after reboot)? Thanks, Niels. > > Read all the details at [1] and to try it on your devices, simply do: > > mkdir /debug > mount -t debugfs none /debug > echo NO_NEW_FAIR_SLEEPERS> /debug/sched_features > > It will magically solve all the problems but i hope it can improve > experience at least somewhat. > > [1] http://marc.info/?l=linux-kernel&m=125260838709566&w=3 _ Reageer op fotoâs van je vrienden en bekijk hun reacties op de jouwe. Gegarandeerd hilariteit! http://www.microsoft.com/belux/nl/windows/windowslive/products/photos.aspx ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
