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
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 Ba
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 sh
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.
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 windo
> 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.
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 timi
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 act
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 b
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 th
> 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 stru
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,
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 k
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 CF
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
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 a
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
> 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/
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
> moun
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/f
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 /debu
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 /d
22 matches
Mail list logo
