All of lore.kernel.org
 help / color / mirror / Atom feed
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/
> 


  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.