On Sun, Aug 26, 2012 at 6:44 PM, Wido <wido...@gmail.com> wrote:
>
>
>
>
> On Sunday August 26 2012 08:36:49 thomasg escribió:
>
>> On Sun, Aug 26, 2012 at 6:58 AM, Carsten Haitzler <ras...@rasterman.com>
>> wrote:
>
>> > On Sun, 26 Aug 2012 05:25:29 +0200 thomasg <tho...@gstaedtner.net> said:
>
>> >
>
>> > i agree that a user should almost never switch frequencies by hand this
>> > is
>
>> > rather pointless. cpufreq allows it - but it's there for tweakers (like
>> > me) so
>
>> > i can even measure power usage at various freqs, performance etc. it's
>> > buried
>
>> > inside a menu so as not to be too convenient.
>
>>
>
>> Yeah sure, having the option for doing testing is great. Imho its just
>
>> not clear enough to users that testing is the only case where using
>
>> this is wise.
>
>> Then again, I don't really have any great idea how to make it not to
>
>> inconvenient for testers, yet inconvenient enough for users :)
>
>> What might work is, making the cpu-freq gadget a "single-click"
>
>> solution. All advanced options in a right-click sub-menu, and simple
>
>> switching between Ondemand and Performance by a single left click.
>
>>
>
>> > imho all we need to do from userspace is switch governors or tweak them.
>> > that
>
>> > means right now powersave / automatic / ondemand / performance. these
>> > governors
>
>> > do not HAVE to keep the cpu at min or max freq. they happen to with
>> > powersave
>
>> > and performance, but conceptually they could switch frequencies around.
>> > if
>
>> > performance can clock down and be done totally imperceptible to
>> > benchmarking,
>
>> > the ui and responsiveness, then why not? but it doesn't.
>
>
>
> I'm all for responsivness. I don't think what I asked is the best solution,
> but it's a mix between responsiveness, performance and bad user habits. A
> checkbox that says 'powersave on blank' or somethink like that. When E goes
> to blank, to lock or to whatever that means the user CAN'T interact with
> GUI, cpufreq switches governor to powersave. When we are at GUI again,
> cpufreq switches to performance (or to the current governor, if you prefer)
>
When it would do that, it wastes power. Because the CPU would still
work, but it would work in a less effective mode.
Powersave forces the CPU to run slow, which makes the CPU run longer
for the same task (and there are always background tasks).
CPUs save most power when they do their work very quickly and go back
to sleep just as quickly.
A few years ago, the most a CPU would do to safe power is to switch
between 2 frequencies.
Modern CPUs will turn off large parts of the chip to safe power which
is much more effective than just changing the frequency.
As I said a couple of times now, just because the screen isn't locked,
doesn't mean the CPU isn't idle. It mostly is.
Would you use that behaviour on a battery powered device, you'd notice
a battery impact of probably beyond 10%.
>
>
>>
>
>> As I said, I'm perfectly happy with the possibility to switch between
>
>> ondemand and performance. Powersave is (mostly) as pointless as
>
>> manual, because it doesn't save power.
>
>>
>
>> > the reality that *I* see is that ondemand/automatic have visible impacts
>> > to
>
>> > the user (other than the fan spinning up/down temperature and power
>
>> > consumption changing). i literally can watch my compile scrolling by
>> > faster
>
>> > switching to performance. its a big jump. it's not a placebo effect. to
>> > prove
>
>> > the point here are numbers for "make clean maintainer-clean;
>> > ./autogen.sh
>
>> > --disable-static && make -j10 && sudo make -j10 install" for e17 on my
>> > machine:
>
>>
>
>> This is true. A area where ondemand still performs badly is I/O-heavy
>
>> operations that generally don't use the CPU much.
>
>> ./configure is something ondemand does really badly.
>
>
>
> compiling or any heavy loaded command can give you times. But go to any
> heavy loaded web site (lots of flash). Go to youtube, watch a fullhd video
> with software render (well, flash doesn't have hardware support for linux),
> you will notice the difference between performance and ondemand. I really
> wouldn't believe if you don't
>
Flash is a perfectly bad example, because it generally does not behave
properly (OTOH, I don't use it any more).
In any case, if the CPU does the video decoding, it will likely always
run at full speed anyway, and ondemand performance impact does not
apply.
>
>
>>
>
>> > (this machine core i5 1.6ghz->3.4ghz, 8gb ram, x86_64, all data on ssd
>> > so no hdd
>
>> > slowness, i ran the exact same compile before the first run to ensure
>> > all
>
>> > caches are warmed up, linux 3.2.0)
>
>> >
>
>> > (maximum speed, automatic, low power automatic, minimum speed)
>
>> > performance : 91 sec
>
>> > ondemand : 122 sec
>
>> > conservative: 113 sec
>
>> > powersave : 198 sec
>
>> >
>
>> > ondemand/powersave are not invisible. it's not a placebo effect. i have
>> > spent
>
>> > my life staring at graphics and animation and i can sometimes SEE the
>
>> > difference with responsiveness just in frame rendering when using these.
>> > i don't
>
>> > have a quick test to prove it but i'm less likely to be affected by
>> > placebo as
>
>> > this is what i have done for most of my life - stare at graphics,
>> > animation and
>
>> > spot single pixel glitches and off-by-1's and incorrect frame timings.
>> > i'm
>
>> > normally very sceptical so if i am seeing an effect, it probably is very
>> > much
>
>> > there. i just don't have a test for you. i could try make one... maybe
>> > measure
>
>> > time from ecore wakeup on event to time until frame render done and
>> > flushed.
>
>> >
>
>> > believe it or not humans do perceive latencies of less than 20ms. you
>> > just
>
>> > can't quite realize what you are perceiving and end up saying "this
>> > thing is
>
>> > slow" when it's fast - it never drops a frame, but.. it's just got
>> > higher
>
>> > latency. 20ms is enough to be 1 frame behind (actually less is enough).
>> > when
>
>> > you get an event u want time from event to result on screen to be as
>> > short as
>
>> > possible. this is because events can come in at ANY time, BUT your
>> > screen is
>
>> > refreshing at a constant fixed rate. higher latencies present themselves
>> > eg as
>
>> > pointer being further ahead of the scrollbar or scrolling content or
>> > window u
>
>> > are moving than normal. if you miss being able to get data in at one
>> > frame, it
>
>> > has to be delayed until the next frame. this ADDS (at 60hz) up to
>> > 16.66ms to
>
>> > your latency of display already. so here's an example.
>
>> >
>
>> > 2ms before the next refresh you get an event. you respond and render.
>> > this
>
>> > rendering take 4ms. oops. you missed the frame. so now your update waits
>
>> > another 14.66ms from the time u finished rendering until user sees it.
>> > total
>
>> > latency from input event to seeing result -> 18.66ms. now to make it
>> > even
>
>> > worse, with compositing we have ANOTHER rendering step - the compositor.
>> > so add
>
>> > some more ms to the rendering time etc. etc. not to mention the slower
>> > your
>
>> > machine (eg cpu clocked down or just old machine) the longer the
>> > rendering time
>
>> > and the more often you end up in this bucket and the longer your
>> > latency. given
>
>> > the right circumstances, if you are JUST fast enough to render frames at
>> > screen
>
>> > refresh given your cpu power etc. then u can be UP to 33ms behind the
>> > event
>
>> > that generated the redraw. this is visible ESPECIALLY if dragging.
>
>> >
>
>> > anyway. my point is that it is measurable and visible. just the numbers
>> > above
>
>> > prove that its not invisible to the user. i can literally see my
>> > compiles go
>
>> > faster ESPECIALLY "configure" goes faster. 6.2s vs 11.4s vs 11.9s vs
>> > 11.9s (as
>
>> > per above governors in that order). almost twice as fast under
>> > performance vs
>
>> > ondemand and automatic. it's visible. it's measurable. the day it is not
>
>> > measurable or visible is the day we can just stop worrying and let the
>> > kernel
>
>> > deal with it, but reality is that this day has not come. i'm all for
>> > saving
>
>> > power, keeping the cpu fan quiet, not generating much heat etc, BUT it's
>> > all
>
>> > still a trade-off and so we ultimately have to give the decision of what
>> > to
>
>> > "give up" in return for what to the user until they no longer need to
>> > care.
>
>>
>
>> That's a bit sad, but still, I think userspace as well as the user
>
>> himself still will make the worst decisions in general.
>
>> The user can say: "I have no interest in saving power" and switch to
>
>> performance, that's fine. The user can even say: "I need full
>
>> performance for an hour" and make the switch between ondemand and
>
>> performance personally, but this really shouldn't be the case on a
>
>> regular basis.
>
>> To be honest: I think that software defined powersaving is a bad idea
>
>> in general. The kernel has the best shot on making this work,
>
>> everything else can only do worse.
>
>
>
> Are you sure? are you really really sure? I'll give you an example. Right
> now, I have E running, I have terminology running and, inside terminollogy,
> I have htop running. If I'm focusing on htop, what do I want to be more
> responsive? htop, that's it. But hey, htop has a priority of 23, terminology
> has 22 and E has 20. So, to the kernel, is more important E than terminology
> and than htop. To me is the exact opposite.
>
These priorities do not come from the kernel, the come from userspace.
htop is a curses application which does refresh its status, at best, a
couple of times per second - by default it even is 1 time per second.
If you tell me, that there was any scenario where it would matter to
you what kind of resources it gets, or even would base power policies
on it, you just proved my point. I.e., if powertop was the only
application running, the CPU would probably spend 2ms every second to
refresh it and go to sleep for 998ms.
With ondemand it would at least waste considerably less power for 988+ms.
>
>
>> In the end this will be going to be done in hardware solely and there
>
>> will be no more software influence, but for now, ondemand still does
>
>> the best job, even if it doesn't always work perfectly.
>
>> The exception proves the rule :)
>
>>
>
>> Anyway, to any user reading this, the thing to take away is: If you
>
>> feel or really are experiencing slowdowns, switch to performance (aka
>
>> "Maximum Speed"), and if you don't love your power bill, switch back
>
>> to automatic afterwards. Never ever ever set the frequency itself
>
>> manually, neither to max., nor to min. or anything in between.
>
>
>
> I think you are underestimating users. I think you are stating that only
> based on your experience. I think you should start thinking that options are
> there to be used, not to constraint users to 'one click'. That's why there
> are 'basic' and 'advanced' options in every E menu, so we 'users' have the
> choice.
>
That's exactly my point. Because the options are there and obvious,
you think they should be used.
Of course I open myself to the argument, that I side with the evil
evil gnome people which want to take all users options...
Don't get me wrong: all the neat options are why I use E for a long
time now, and I certainly don't want them gone. However, some options
are contra-productive mostly and seduce users to use them unwisely.
For what its worth: the basic and advanced options are largely arbitrary.
The advanced menus include a ton of basic options which are not
advanced at all, and the basic menus include some advanced options.
There's a good reason, that hardly any of the newer configuration
menues even include Basic/Advanced anymore, most just use a toolbar
("tabs"), which is basically the way Basic/Advanced was used already
(the composite module is pretty much the only module I can think of
where it makes sense).
>
>
>>
>
>> >> On Sun, Aug 26, 2012 at 12:43 AM, Wido <wido...@gmail.com> 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 <wido...@gmail.com> 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 <wido...@gmail.com> 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
>
>> >> >
>
>> >> >> >
>
>> >> >
>
>> >> >> >> > enlightenment-users@lists.sourceforge.net
>
>> >> >
>
>> >> >> >
>
>> >> >
>
>> >> >> >> >
>> >> >> >> > 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
>
>> >> >
>
>> >> >> >
>
>> >> >
>
>> >> >> >> enlightenment-users@lists.sourceforge.net
>
>> >> >
>
>> >> >> >
>
>> >> >
>
>> >> >> >> https://lists.sourceforge.net/lists/listinfo/enlightenment-users
>
>> >> >
>
>> >> >> >
>
>> >> >
>
>> >> >> >>
>
>> >> >
>
>> >> >> >
>
>> >> >
>
>> >> >> > ________________________________
>
>> >> >
>
>> >> >> >
>
>> >> >
>
>> >> >> > Wido
>
>> >> >
>
>> >> >>
>
>> >> >
>
>> >> > ________________________________
>
>> >> >
>
>> >> > 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
>
>> >> enlightenment-users@lists.sourceforge.net
>
>> >> https://lists.sourceforge.net/lists/listinfo/enlightenment-users
>
>> >
>
>> >
>
>> > --
>
>> > ------------- Codito, ergo sum - "I code, therefore I am" --------------
>
>> > The Rasterman (Carsten Haitzler) ras...@rasterman.com
>
>> >
>
>>
>
> ________________________________
>
> 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
enlightenment-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-users
