Prev: docbook: make mtd nand module init static
Next: linux-next: build failure in Linus' tree
From: Peter Zijlstra on 26 May 2010 09:00
On Wed, 2010-05-26 at 13:35 +0100, Alan Cox wrote:

> This is an area where machines are improving and where the ability to
> do stuff like autosuspend, the technology like the OLPC screen and so on
> create an incentive for the BIOS and platform people to improve their
> bits of it.

But do you think its a sensible thing to do? Explicitly not running
runnable tasks just sounds wrong. Also, at the extreme end, super fast
suspend is basically an efficient idle mode.

Why would the code holding suspend blockers be any more or less
important than any other piece of runnable code.

In fact, having runnable but non suspend blocking tasks around will
delay the completion of the suspend blocker, so will we start removing
those?

This whole thing introduces an artificial segregation of code. My 'cool'
code is more important than your 'uncool' code. Without a clear
definition of what makes code cool or not.

> > So yes, I do think merging this will delay the effort in fixing
> > userspace, simply because all the mobile/embedded folks don't care about
> > it anymore.
>
> The mobile space probably doesn't care too much about many of the large
> bloated desktop apps anyway and traditional embedded generally has a very
> small fixed application set where the optimise both halves of the system
> together.

Sure, but at least we share the kernel. It was said that the kernel
generates too many wakeups (and iwlagn certainly is the top most waker
on my laptop). Improvements to the kernel will benefit all, regardless
of whatever userspace we run.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Zygo Blaxell on 26 May 2010 16:30
On Wed, May 26, 2010 at 02:53:16PM +0200, Peter Zijlstra wrote:
> On Wed, 2010-05-26 at 13:35 +0100, Alan Cox wrote:
> > This is an area where machines are improving and where the ability to
> > do stuff like autosuspend, the technology like the OLPC screen and so on
> > create an incentive for the BIOS and platform people to improve their
> > bits of it.
>
> But do you think its a sensible thing to do? Explicitly not running
> runnable tasks just sounds wrong.
[...]
> Why would the code holding suspend blockers be any more or less
> important than any other piece of runnable code.

With my userspace developer hat on, I'd *kill* for a way to tell
the kernel that there are more important things for the system to
be doing than executing my runnable task. In some cases, the set of
"more important things" the system might include running other tasks,
but it also might include conserving power. I'd like to have my program
tell the kernel things like "wake me up in 0.1 seconds, plus or minus
a year if you have something better to do."

With my sysadmin hat on (which is nearly identical to my phone owner hat,
BTW), I'd like whatever syscall implements those features to take a PID
argument, so I can impose my importance decisions on other processes.
I'd also like to set the relative importance of keeping the CPU idle on
the same scale, so that I could raise or lower the importance of keeping
the CPU idle as power availability changes.

> This whole thing introduces an artificial segregation of code. My 'cool'
> code is more important than your 'uncool' code. Without a clear
> definition of what makes code cool or not.

It's impossible in the general case for an application to know whether
it's important or not, so it's also impossible for the kernel to derive
this information from the application's behavior--and impossible, in the
general case, to decide whether the application is more important than the
battery or some other scarce resource the kernel might also be managing
(e.g. if the machine is running hot, heat dissipation might be scarce,
and we'd want to be idle then too). This is similar to niceness and
SCHED_RR/FIFO: there's no way for the kernel to automatically assign
those values either, they have to be specified by a user or administrator.
Of course, programs are free--within limits--to specify these values
about themselves.

Consider a traditional Unix program like "sort". Seriously, how is "sort"
supposed to know that it's the most important application on the system
(because I need my contacts list alphabetized *now*), or the least
(because the screensaver needs to know which is the oldest graphics
hack in the list)?

"sort" gets invoked from a shell, cooperating with other processes to do
its work. It knows very little about the context in which it is executing
(nor should it). Should "sort" sprout command-line arguments for every
possible scheduling latency and power management policy option, or should
"sort" not care, and defer such decisions to other command-line
tools which set these options before exec()ing "sort", or to a management
utility like "top" that implements policy across the entire system?

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Arve Hjønnevåg on 26 May 2010 19:00
2010/5/26 Peter Zijlstra <peterz(a)infradead.org>:
> On Wed, 2010-05-26 at 03:53 -0700, Arve Hj�nnev�g wrote:
>> 2010/5/26 Peter Zijlstra <peterz(a)infradead.org>:
>> > On Wed, 2010-05-26 at 03:40 -0700, Arve Hj�nnev�g wrote:
>> >> 2010/5/26 Peter Zijlstra <peterz(a)infradead.org>:
>> >> > On Wed, 2010-05-26 at 03:25 -0700, Arve Hj�nnev�g wrote:
>> >> >
>> >> >> and on systems where the
>> >> >> same power state can be used from idle and suspend, we use suspend so
>> >> >> we can stay in the low power state for minutes to hours instead of
>> >> >> milliseconds to seconds.
>> >> >
>> >> > So don't you think working on making it possible for systems to be idle
>> >> > _that_ long would improve things for everybody? as opposed to this
>> >> > auto-suspend which only improves matters for those that (can) use it?
>> >>
>> >> I'm not preventing anyone from working on improving this. Currently
>> >> both the kernel and our user-space code polls way too much. I don't
>> >> think it is reasonable to demand that no one should run any user-space
>> >> code with periodic timers when we have not even fixed the kernel to
>> >> not do this.
>> >
>> > All I'm saying is that merging a stop-gap measure will decrease the
>> > urgency and thus the time spend fixing the actual issues while adding
>> > the burden of maintaining this stop-gap measure.
>> >
>>
>> Fixing the actually issue means fixing all user-space code, and
>> replacing most x86 hardware. I don't think keeping this feature out of
>> the kernel will significantly accelerate this.
>
> I don't think x86 is relevant anyway, it doesn't suspend/resume anywhere
> near fast enough for this to be usable.

x86 systems already auto-suspend.

>
> My laptop still takes several seconds to suspend (Lenovo T500), and
> resume (aside from some userspace bustage) takes the same amount of
> time. That is quick enough for manual suspend, but I'd hate it to try
> and auto-suspend.
>

Why? If your suspend is currently set to sleep after 30 minutes of
inactivity, you can still have the same setting with opportunistic
suspend. With opportunistic suspend you can have an alarm set to run a
task at a specific time without risking that this task does not run at
that time just because your inactivity timer expired at the same time
as the alarm went off.

> Getting longer idle periods however is something that everybody benefits
> from. On x86 we're nowhere close to hitting the max idle time of the
> platform, you get _tons_ of wakeups on current 'desktop' software.
>
> But x86 being a PITA shouldn't stop people from working on this, there's
> plenty other architectures out there, I remember fixing a NO_HZ bug with
> davem on sparc64 because his niagra had cores idling for very long times
> indeed.
>
> So yes, I do think merging this will delay the effort in fixing
> userspace, simply because all the mobile/embedded folks don't care about
> it anymore.
>

To me this is not a good argument for not merging the code. If people
stop caring about the problem if this feature is merged that means it
solved a problem for them. You want to prevent merging a feature
_because_ it solves a problem.

--
Arve Hj�nnev�g
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
First  |  Prev  | 
Pages: 1 2 3 4 5 6
Prev: docbook: make mtd nand module init static
Next: linux-next: build failure in Linus' tree