From: Gregory Haskins <gregory.haskins.ml@gmail.com>
To: Mark Hansen <Mark.Hansen@cirrusrtps.com.au>
Cc: linux-kernel@vger.kernel.org, Ingo Molnar <mingo@elte.hu>,
rostedt@goodmis.org
Subject: Re: priority based thread wakeup
Date: Fri, 18 Jan 2008 08:33:59 -0500 [thread overview]
Message-ID: <4790AAC7.2080703@gmail.com> (raw)
In-Reply-To: <L669EA1BDC369453cA3ACCF0A75D0F5A3.1200638498.mail.cirrusrtps.com.au@MHS>
Mark Hansen wrote:
> Hello,
>
> Firstly, may I apologise as I am not a member of the LKML, and ask that
> I be CC'd in any responses that may be forthcoming.
>
> My question concerns the following patch which was incorporated into the
> 2.6.22 kernel (quoted from that change log):
>
>> Today, all threads waiting for a given futex are woken in FIFO
>> order (first waiter woken first) instead of priority order.
>>
>> This patch makes use of plist (pirotity ordered lists) instead
>> of simple list in futex_hash_bucket.
>>
>> All non-RT threads are stored with priority MAX_RT_PRIO, causing
>> them to be woken last, in FIFO order (RT-threads are woken first,
>> in priority order).
>>
>> Signed-off-by: Sebastien Dugue <sebastien.du...@bull.net>
>> Signed-off-by: Pierre Peiffer <pierre.peif...@bull.net>
>
> After updating to this version of the kernel, I was able to observe the
> above fix, where multiple RT threads invoking pthread_cond_wait(), and
> the highest priority thread will acquire the mutex first, after the
> thread holding the mutex calls pthread_cond_signal();
> pthread_mutex_unlock()
>
> However, since kernel 2.6.23, it seems that the functionality relating
> to this "priority based wakeup" has disappeared.
>
> I understand there have been significant changes in this kernel
> concerning the "Completely Fair Scheduler" replacing the "mainline"
> scheduler; however my understanding is that the RT functionality would
> be preserved. This does not appear to be the case based on repeating the
> experiment described above.
>
> I was wondering if this functionality is considered no longer
> desirable/necessary?
>
> If not, is it anticipated that this functionality could/would be
> included in a later kernel?
>
Hi Mark,
In a coffee deprived stupor ;), I responded to this mail in the wrong
thread, here:
http://lkml.org/lkml/2008/1/18/207
Sorry for the confusion
HTH
-Greg
> Regards,
> Mark Hansen
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
next prev parent reply other threads:[~2008-01-18 13:34 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-18 6:31 priority based thread wakeup Mark Hansen
2008-01-18 13:33 ` Gregory Haskins [this message]
2008-01-21 4:17 ` Mark Hansen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4790AAC7.2080703@gmail.com \
--to=gregory.haskins.ml@gmail.com \
--cc=Mark.Hansen@cirrusrtps.com.au \
--cc=gregory.haskins@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=rostedt@goodmis.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.