All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Bhavesh P. Davda" <bhavesh@avaya.com>
To: "Richard Seaman, Jr." <dick@seaman.org>
Cc: mingo@elte.hu, linux-kernel@vger.kernel.org,
	Linus Torvalds <torvalds@transmeta.com>
Subject: Re: [PATCH] SCHED_FIFO and SCHED_RR scheduler fix, kernel 2.4.18
Date: Thu, 13 Jun 2002 16:43:38 -0600	[thread overview]
Message-ID: <3D09201A.5060305@avaya.com> (raw)
In-Reply-To: <Pine.LNX.4.44.0206132007010.8525-100000@elte.hu> <3D090B4D.4060104@avaya.com> <20020613171101.A20472@seaman.org>

And my patch *MAKES* it compliant with these definitions. The scheduler 
was *NOT* compliant with these definitions.

You've quoted me out of context below. My statement that you quote 
applies to SCHED_OTHER processes.

Please see my original post with the patch. And thanks for reinforcing 
what I was saying!

- Bhavesh

Richard Seaman, Jr. wrote:
> On Thu, Jun 13, 2002 at 03:14:53PM -0600, Bhavesh P. Davda wrote:
> 
> 
>>I would think that the logical place to add any process to the runqueue 
>>would be the back of the runqueue. If all processes are ALWAYS added to 
>>the back of the runqueue, then every process is GUARANTEED to eventually 
>>be scheduled. No process will be starved indefinitely.
> 
> 
> FYI, from SuSv3:
> 
> "Under the SCHED_FIFO policy, the modification of the definitional
> thread lists is as follows:
> 
> 1. When a running thread becomes a preempted thread, it becomes
> the head of the thread list for its priority.
> 
> 2. When a blocked thread becomes a runnable thread, it becomes
> the tail of the thread list for its priority.
> 
> ....
> 
> 7. If a thread whose policy or priority has been modified other
> than by pthread_setschedprio() is a running thread or is runnable,
> it then becomes the tail of the thread list for its new priority.
> 
> 8. If a thread whose policy or priority has been modified by
> pthread_setschedprio() is a running thread or is runnable, the
> effect on its position in the thread list depends on the direction
> of the modification, as follows:
> 
>    1. If the priority is raised, the thread becomes the tail of
>       the thread list.
>    2. If the priority is unchanged, the thread does not change
>       position in the thread list.
>    3. If the priority is lowered, the thread becomes the head
>       of the thread list.
> 
> 9. When a running thread issues the sched_yield() function, the
> thread becomes the tail of the thread list for its priority.
> 
> ...."
> 
> Also, regarding SCHED_RR:
> 
> "...This policy shall be identical to the SCHED_FIFO policy with the
> additional condition that when the implementation detects that a
> running thread has been executing as a running thread for a time
> period of the length returned by the sched_rr_get_interval() function
> or longer, the thread shall become the tail of its thread list and
> the head of that thread list shall be removed and made a running
> thread......"
> 
> I'm not suggesting Linux HAS to comply with these requirements,
> but its worth consideration.
> 



-- 
Bhavesh P. Davda
Avaya Inc
Room B3-B03                     E-mail : bhavesh@avaya.com
1300 West 120th Avenue          Phone  : (303) 538-4438
Westminster, CO 80234           Fax    : (303) 538-3155


      reply	other threads:[~2002-06-13 22:43 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-06-12 16:19 [PATCH] SCHED_FIFO and SCHED_RR scheduler fix, kernel 2.4.18 Bhavesh P. Davda
2002-06-13 18:36 ` Ingo Molnar
2002-06-13 21:14   ` Bhavesh P. Davda
2002-06-13 21:24     ` Robert Love
2002-06-13 21:27       ` Ingo Molnar
2002-06-13 21:35     ` Ingo Molnar
2002-06-13 22:11     ` Richard Seaman, Jr.
2002-06-13 22:43       ` Bhavesh P. Davda [this message]

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=3D09201A.5060305@avaya.com \
    --to=bhavesh@avaya.com \
    --cc=dick@seaman.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=torvalds@transmeta.com \
    /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.