[alsa-devel] [RFC PATCH] ALSA: hda - Implement a poll loop for jacks as a module parameter

[Takashi Iwai]

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