Re: [PATCH][RFC] time: add wait_interruptible_timeout macro to sleep (w. timeout) until wake_up

From: RafaÅ MiÅecki
Date: Fri Feb 26 2010 - 12:34:06 EST


W dniu 26 lutego 2010 17:14 uÅytkownik Andrew Morton
<akpm@xxxxxxxxxxxxxxxxxxxx> napisaÅ:
> On Fri, 26 Feb 2010 11:38:59 +0100 Rafa Miecki <zajec5@xxxxxxxxx> wrote:
>
>> +#define wait_interruptible_timeout(wq, timeout)
>> Â Â \
>> +({ Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â \
>> + Â Âlong ret = timeout; Â Â Â Â Â Â Â Â Â Â Â\
>> + Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â\
>> + Â ÂDEFINE_WAIT(wait); Â Â Â Â Â Â Â Â Â Â Â\
>> + Â Âprepare_to_wait(&wq, &wait, TASK_INTERRUPTIBLE); Â Â Â \
>> + Â Âif (!signal_pending(current)) Â Â Â Â Â Â Â Â Â\
>> + Â Â Â Âret = schedule_timeout(ret); Â Â Â Â Â Â\
>> + Â Âfinish_wait(&wq, &wait); Â Â Â Â Â Â Â Â Â \
>> + Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â\
>> + Â Âret; Â Â Â Â Â Â Â Â Â Â Â Â Â Â \
>> +})
>
> It's often a mistake to use signals in-kernel. ÂSignals are more a
> userspace thing and it's better to use the lower-level kernel-specific
> messaging tools in-kernel. ÂBear in mind that userspace can
> independently and asynchronously send, accept and block signals.

Can you point me to something kernel-level please?


> Can KMS use wait_event_interruptible_timeout()?

No. Please check definition of this:

#define wait_event_interruptible_timeout(wq, condition, timeout) \
({ \
long __ret = timeout; \
if (!(condition)) \
__wait_event_interruptible_timeout(wq, condition, __ret); \
__ret; \
})

It uses condition there, but that's not a big issue. We just need to
pass 0 (false) there and it will work so far.

But then check __wait_event_interruptible_timeout definition, please.
It goes into sleep and after waking up it checks for value returned by
schedule_timeout. That's what breaks our (needed by radeon) sleeping.
If timeout didn't expire it does into sleep again!

What we need is continue reclocking after waking up. If this has
happend before timeout expired, that means we was woken up by VBLANK
interrupt handler. We love that situation and we do not want to go
sleep again.

On the other hand we need to have some timeout in case VBLANK
interrupt won't come.

--
RafaÅ
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/