At Wed, 10 Oct 2012 17:36:58 +0200, David Henningsson wrote:
On 10/10/2012 04:07 PM, Takashi Iwai wrote:
At Wed, 10 Oct 2012 15:47:31 +0200, David Henningsson wrote:
On 10/09/2012 04:57 PM, Takashi Iwai wrote:
At Tue, 09 Oct 2012 16:28:07 +0200, David Henningsson wrote:
Or, to make it a bit more pragmatic, what other things are broken with single_cmd? Could you give an example where this change would be harmful?
The single cmd mode itself was introduced as a sort of rescue command without CORB/RIRB. We shouldn't use it in normal situations. It's simply no considered use case.
With a lack of unsol event, you can't handle the volume knob, or any GPIO events, too.
Those two are quite uncommon, and can be polled too if necessary.
I wonder from where your love to polling comes...
It's not a love for polling. It's a pragmatic view of having people's machines working at best effort.
I'm not against to implement the polling if the hardware is really broken and doesn't emit the unsol event properly. But preferring the poll is a different question. The poll should be always a second choice.
If we, due to lack of time, hardware, specifications, whatever, can't have the best option available to our users, I prefer to have it working but "secretly performing worse", to not having it working at all.
It works more or less but just without unsol event. It should be enough not to stop most of works, but enough for people noticing the problem they face. Again, if single_cmd mode fallback happens, something must be wrong. This is the thing to be fixed.
I'm genuinely trying to understand what's so wrong with single cmd mode *in practice*, but when what I get in return from you is stuff about saving the world and peaceful living, I don't know how to interpret that "information".
Using single_cmd mode is like driving a car only with the side brake.
Well, do you want to allow 1ms polling?
I can't see why not, if people want to burn CPU cycles, why not let them.
You seem to trust users too much :)
Well, there's already a single_cmd module parameter, which if enabled causes "no peaceful living at all", can't be worse than that, can it? ;-)
It's a completely different problem. Don't mix up the single_cmd with too frequent polling.
You are trying to allow user setting up a parameter which may freeze the machine immediately by 100% CPU hog. It won't happen with single_cmd mode option.
However, the real limit should probably be one jiffy, so attaching modified patch. If you think there should be another lower limit, feel free to adjust the patch before applying. It's no big deal.
Well, do you really think 1 jiffies is the _sane_ lower limit for this polling behavior? (And did you imagine what would happen if doing it on a non-preemptive kernel?)
Hypothetically we may set any value. But whether it really helps in practice, one needs to think twice.
My imagination would be that it wouldn't be terribly slow, as there's always at least a jiffy between poll runs, that could be used for other tasks. But I haven't tried it.
I doubt we'll get a lot of bug reports from people who have set the poll interval to 1 ms and then complaining about bad performance. If we do, we could set a limit.
Hmm... I really don't understand why you want to allow such an insane value at all. What benefit will you have by allowing 1ms jiffies?
1 ms is obviously a wrong choice.
Takashi