Re: [e-users] New tiny feature request

[thomasg <th...@gs...>]

On Sun, Aug 26, 2012 at 12:43 AM, Wido <wi...@gm...> wrote:
>
>
>
>
> On Saturday August 25 2012 15:29:17 thomasg escribió:
>
>> I'm sorry, but your assumptions are fundamentally flawed.
>
>>
>
>> On Sat, Aug 25, 2012 at 7:09 PM, Wido <wi...@gm...> wrote:
>
>> > ondemand works based on priorities, not idliness. For example, in my
>> > debian
>
>>
>
>> It does not.
>
>> However, it somewhat does take priority into account, which you can
>
>> disable by passing ignore_nice_load=1 as parameter to the ondemand
>
>> cpufreq kernel module.
>
>
>
> You are right, my bad. I forgot to add
>
>
>
> "2.4 Ondemand
>
> ------------
>
>
>
> The CPUfreq governor "ondemand" sets the CPU depending on the
>
> current usage. To do this the CPU must have the capability to
>
> switch the frequency very quickly." (from kernel.org)
>
> that means, it changes the freq based in usage, the more cpu usage, the
> higher the speed. That 's what I mean when I say 'not idliness'. Idliness
> would mean, not touching your computer for a while
>

No, idleness is the CPU not having to do any work for a while (a while
in kernel terms is some nanoseconds).
So even if you don't touch your machine for a day, it might not be
idle, because it might execute some software in the background.
On the other hand, the machine can be idle even if you sit in front of
it, because it is much better and infinitely faster in making
decisions than any human, and so it will reduce its clock in this time
as well.

>>
>
>> > testing, my regular desktop apps have a priority of 23, so ondemand not
>
>> > always rises the speed as I would like. Other example is when you go to
>
>> > lunch, you usually just lock your screen, but how many really lower
>> > power
>
>>
>
>> cpufreq handles the cpu, what the screen does is absolutely irrelevant.
>
>> The CPU will still run when you turn off or even unplug your screen,
>
>> it simply does not care.
>
>> Locking the screen does not magically reduce power consumption.
>
>
>
> I know the screen has nothing to do. But I think locking and E's own
> screensaver feature are somehow linked, so I assumed it would, somehow, pass
> it 'state' to the modules, or the modules would be able to know if E is
> locked or with screensaver.
>

They are not linked, the screen saver has only very few actions it can
take and will never inform any other module.

>
>
>>
>
>> > consumption? yeah, it's a stupid scenario, but is the one I'm interested
>> > (or
>
>> > when I go to sleep without shuting down the computer and forget to
>> > chance
>
>> > power policy).
>
>>
>
>> You should never change power policy manually, except for very rare
>
>> cases where automatic policies don't work.
>
>> In almost any case that is contra-productive and you generally will
>
>> waste energy (and your own time) needlessly.
>
>> What you want is suspend to ram.
>
>> e17 can even automatically suspend your computer when it is idle long
>
>> enough (via the screen saver).
>
>
>
> Changing the policy from the cpufreq module, not 'by hand' (I'm assuming
> that 'by hand' means writing to
> /sys/devices/system/cpu/cpuX/cpufreq/scaling_governor, right). When did I
> imply 'by hand'?
>

You are always implying by hand, which in this case is manually using
the e17 cpu-freq frontend to change policy and frequency.

I already said that in the past: the cpufreq module should not be
enabled by default, because it suggests users, that it may be wise to
use it.
Most of the time, it isn't.
It is (almost always) useless information and (almost always) contraproductive.

>
>
>>
>
>> >
>
>> >
>
>> > And, the idea is that cpufreq module changes the freq (something it
>> > already
>
>> > does), not to rewrite a new power policy.
>
>> >
>
>>
>
>> It does not. It has no policy code, it will only display the status
>
>> quo via the kernels cpu-freq infrastructure.
>
>
>
> It does no changes the freq? I'm sorry, but when I do 'click -> cpu velocity
> -> 2.3' I'm not changing the freq? policy or not policy, it can force the
> current frequency. I know it can because I do that all the time, what I
> would like is that it changes to the minimum frequency available when E is
> completelly idle.
>

The module itself does not change the frequency.
If you chose the frequency via the module, what happens is:
1) ask cpu-freq to switch to the userspace governor
2) ask cpu-freq to set a certain p-state (frequency)

Both is a terrible idea, as both costs you a) performance and b) energy.
The userspace governor forces the user to make his own policy and make
all adjustments by hand.
This is a terrible idea, because every user (even the most skilled and
smart ones) makes terrible decisions.
Setting the CPU to a low frequency costs you performance because the
cpu can't switch to a fast state, but it also costs you power, because
the cpu is less effective at lower frequencies and high load.
Setting the CPU to a high frequency does not cost you performance but
it constantly costs you power because the system cannot reduce
voltage, has to run at high frequencies for mostly no reasons (your
CPU is hardly ever working) and it will disable some hardware internal
powersaving mechanisms.

What would be acceptable is to switch from the ondemand governor
(default) to "performance" in case of a negative performance impact of
ondemand, which is rare and the majority of users will likely never
experience.
I strongly believe, that the userspace governor is a terrible idea,
distros should not offer it by default to users, and e17 should not
offer it by default via the cpufreq gadget. It basically is a button
that says "please computer, waste some energy!"

>
>
>
>
>
>
> Today I was thinking what other scenarios would be usefull for this. Then, I
> remembered that E is very versatile, it can fit in a car's audio system, in
> a home theater, a cell phone or even a fridge. I know that ondemand would
> fit most of this scenarios, but ondeman works continuously. That means that
> if you don't input something for a couple seconds, freq tends to go down
> again. I've used ondemand in a laptop that I had (thinkpad t61, not the best
> but pretty good), the response time when in ondemand were not as I would
> expect. I ended up with forcing full speed and ondemand when in battery (not
> 'by hand' but using cpufrq module).
>

Generally, ondemand will switch state in under a few milliseconds and
you will never notice.
There are rare cases when ondemand will switch back and forth because
of an unusual usage pattern, but I never encountered it since 2005 or
so.

>
>
> So imagine a fridge, working 24/7, you could have a cpu that has 3 or 4
> speeds (don't know how much ARM can have). When the user acctually uses the
> fridge panel, you go to full speed, making as responsible as possible. When
> nobody touches it, you go to min speed saving consuption. Same scenario
> applies for cellphones. Ondeman works, yes, but as it works continually, it
> may low freq, making the system less responsive.
>

This is exactly what ondemand does.
I do not believe you ever noticed any latency impact, because ondemand
will switch much much faster than you could possibly tell.
If you really did, and the cpufreq modules heavy placebo/nocebo-effect
didn't play a trick on you, something else was probably
mis-configured.

Ondemand will, in default configuration on modern desktop systems,
evaluate and change the frequency every 10 ms -- human eyes have
latencies between 20 and 50 ms. And even then, it might not even be
necessary to change the frequency for simple UI stuff, because the CPU
might be done in under 10ms already and give cpu-freq no reason to
switch state.

Anyway, to come back to your core point: I do not believe it is wise
to implement such policy in userspace, because userspace does not have
the facts to evaluate. Basically the only decision E could make here
would be to use the performance governor when the computer is actively
used - but this is a terrible idea, because the CPU on a personal
computer being actively used is still idle for far beyond 99% of the
time.

>
>
>
>
>>
>
>> >
>
>> >
>
>> > On Saturday August 25 2012 13:54:54 thomasg escribió:
>
>> >
>
>> >> On Sat, Aug 25, 2012 at 3:35 AM, Wido <wi...@gm...> wrote:
>
>> >
>
>> >> > Hi!
>
>> >
>
>> >> >
>
>> >
>
>> >> > Yesterday I was thinking (yeah, sometimes I do that...specially when
>
>> >> > trying to fall asleep), would it be possible to add an option to the
>> >> > cpufreq
>
>> >> > module that, when E goes idle, the freq goes to th min value, and
>> >> > when you
>
>> >> > resume it goes back to the setting it had before.
>
>> >
>
>> >> >
>
>> >
>
>> >> > This way, if you want, you can use powersave when not doing anything.
>
>> >
>
>> >> >
>
>> >
>
>> >> >
>
>> >
>
>> >> > cheers
>
>> >
>
>> >> >
>
>> >
>
>> >> >
>
>> >
>
>> >> > Wido
>
>> >
>
>> >> >
>
>> >> >
>> >> > ------------------------------------------------------------------------------
>
>> >
>
>> >> > Live Security Virtual Conference
>
>> >
>
>> >> > Exclusive live event will cover all the ways today's security and
>
>> >
>
>> >> > threat landscape has changed and how IT managers can respond.
>
>> >> > Discussions
>
>> >
>
>> >> > will include endpoint security, mobile security and the latest in
>
>> >> > malware
>
>> >
>
>> >> > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>
>> >
>
>> >> > _______________________________________________
>
>> >
>
>> >> > enlightenment-users mailing list
>
>> >
>
>> >> > enl...@li...
>
>> >
>
>> >> > https://lists.sourceforge.net/lists/listinfo/enlightenment-users
>
>> >
>
>> >>
>
>> >
>
>> >> That's what the linux kernels ondemand cpufreq governor already does,
>
>> >
>
>> >> I don't see any reason why something that already is done should be
>
>> >
>
>> >> reimplemented in userspace (which could only be done poorly).
>
>> >
>
>> >>
>
>> >
>
>> >>
>
>> >>
>> >> ------------------------------------------------------------------------------
>
>> >
>
>> >> Live Security Virtual Conference
>
>> >
>
>> >> Exclusive live event will cover all the ways today's security and
>
>> >
>
>> >> threat landscape has changed and how IT managers can respond.
>> >> Discussions
>
>> >
>
>> >> will include endpoint security, mobile security and the latest in
>> >> malware
>
>> >
>
>> >> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>
>> >
>
>> >> _______________________________________________
>
>> >
>
>> >> enlightenment-users mailing list
>
>> >
>
>> >> enl...@li...
>
>> >
>
>> >> https://lists.sourceforge.net/lists/listinfo/enlightenment-users
>
>> >
>
>> >>
>
>> >
>
>> > ________________________________
>
>> >
>
>> > Wido
>
>>
>
> ________________________________
>
> Wido