> B try to complete but cpu timer keep firing and at 8 it is time out.
> My platform is mips and is there any possibility to only let cpu timer
> be preemptible?
>
This seems really strange because when B calls complete, it sets up
condition variable value i.e. completion->done++ by disabling the
local interrupts. Following is code snippet from complete function:
spin_lock_irqsave(&x->wait.lock, flags);
// This will disable interrupts
x->done++;
// signals completion
__wake_up_common(&x->wait, TASK_NORMAL, 1, 0, NULL);
spin_unlock_irqrestore(&x->wait.lock, flags);
So now even if process A does not get a chance to execute and
completion timeout occurs before that, as you have shown in your
example, process A would still correctly knows about completion
because x->done was already set. Pleas look at the code snippet for
do_wait_for_common called from wait_for_completion_timeout:
if (!x->done) {
....
do {
....
} while (!x->done && timeout);
__remove_wait_queue(&x->wait, &wait);
if (!x->done)
return timeout;
}
x->done--;
return timeout ?: 1;
>From above code, even if timeout expires i.e. timeout=0 and x->done is
already set, this function will still return 1.
> BTW, in x86 or other ARCH, will they try to let timer ISR be preemptible?
completion functions taking spin_lock_irqsave, so timer ISR should not
preempt the complete API.
Rajat
On Fri, Jan 7, 2011 at 7:51 PM, loody <miloody@xxxxxxxxx> wrote:
>
> hi all:
>
> 2011/1/6 Rajat Sharma <fs.rajat@xxxxxxxxx>:
> > Hi loody,
> >
> > calling complete will make the waiter process runnable but won't
> > necessarily switch to waiter thread and make it run. Its upto
> > scheduler to pick this process from run queue and execute based on its
> > priority value. I think there is not deterministic time in which the
> > waiter process will start executing.
> >
> > Probably what you want to do is calibrate timeout value in
> > wait_for_completion_timeout. I would suggest to do a binary search
> > between minimum timeout value (latency by which function A calls
> > complete, though this process can also schedule in between) to max
> > value (max your application can afford).
> >
> > Rajat
> >
> > On Thu, Jan 6, 2011 at 1:35 PM, loody <miloody@xxxxxxxxx> wrote:
> >> hi:
> >>
> >> 2011/1/6 Pavan Savoy <pavan_savoy@xxxxxxxx>:
> >>> On Thu, Jan 6, 2011 at 12:23 PM, loody <miloody@xxxxxxxxx> wrote:
> >>>> hi:
> >>>>
> >>>> 2011/1/6 Pavan Savoy <pavan_savoy@xxxxxxxx>:
> >>>>> On Thu, Jan 6, 2011 at 11:48 AM, loody <miloody@xxxxxxxxx> wrote:
> >>>>>>
> >>>>>> Dear all:
> >>>>>> I know complete will wake up the process who call wait_complete.
> >>>>>> Is there any methods I can use to measure how long from calling
> >>>>>> complete to the process that detect done=1?
> >>>>>> Regards,
> >>>>>> miloody
> >>>>>
> >>>>> returned value of wait_for_completion_timeout ?
> >>>> No.
> >>>> I want to measure the duration of complete to the time of wake up
> >>>> process who is pending on wait.
> >>>
> >>> Ah, Ok, Got it...
> >>> I would do a copy of jiffies before the complete and do a diff for
> >>> jiffies after the
> >>> wait_for_ ...
> >>>
> >>> I suppose there would be much more better/optimized way ....
> >> thank U :)
> >> why I ask so is I am porting kernel to other platform right now.
> >> and I found the time of getting complete is too long.
> >> What I mean is
> >> function A call wait_complete_timeout
> >> function B complete
> >> theoretically A will get complete and leave successfully
> >> but my platform A will told me that before timeout the complete is not got.
>
> I doubt my problem comes from cpu timer interrupt is so often such
> that when function B get the change to complete, the left time is
> almost exhausted.
> for not to be confused, I take following jiffies for example:
> 1 2 3 4 5
> 6 8
> start wait B try complete
> time out
>
> B try to complete but cpu timer keep firing and at 8 it is time out.
> My platform is mips and is there any possibility to only let cpu timer
> be preemptible?
>
> BTW, in x86 or other ARCH, will they try to let timer ISR be preemptible?
>
>
> --
> Regards,
> miloody
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies@xxxxxxxxxxxxxxxxx
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
