Re: wake_up vs. wake_up_sync
Manfred,
Calling this a BUG is misleading. It is ok to be occasionally wrong
regarding the preemption priority as long as RT tasks are not involved.
This is due to the fact that PROC_CHANGE_PENALTIES are used, which already
provide for some priority inversion.
Hubertus Franke
email: [EMAIL PROTECTED]
(w) 914-945-2003(fax) 914-945-4425 TL: 862-2003
Manfred Spraul <[EMAIL PROTECTED]>@vger.kernel.org on 06/27/2001
06:41:29 PM
Sent by: [EMAIL PROTECTED]
To: Mike Kravetz <[EMAIL PROTECTED]>
cc: Scott Long <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
Subject: Re: wake_up vs. wake_up_sync
Mike Kravetz wrote:
>
> On Wed, Jun 27, 2001 at 11:22:19PM +0200, Manfred Spraul wrote:
> > > Why would you want to prevent
> > > reschedule_idle()?
> > >
> > If one process runs, wakes up another process and _knows_ that it's
> > going to sleep immediately after the wake_up it doesn't need the
> > reschedule_idle: the current cpu will be idle soon, the scheduler
> > doesn't need to find another cpu for the woken up thread.
>
> I'm curious. How does the caller of wake_up_sync know that the
> current cpu will soon be idle. Does it assume that there are no
> other tasks on the runqueue waiting for a CPU? If there are other
> tasks on the runqueue, isn't it possible that another task has a
> higher goodness value than the task being awakened. In such a case,
> isn't is possible that the awakened task could sit on the runqueue
> (waiting for a CPU) while tasks with a lower goodness value are
> allowed to run?
>
I found one combination where that could happen:
process.thread
A.1: highest priority, runs on cpu0
B.1: lowest priority, runs on cpu1
A.2: another thread of process A, priority
PROC_CHANGE_PENALTY+PRIORITY(B.1)+1, sleeping.
B.2: same priority as A.2, sleeping, same process as B.1
A.1:
{
wake_up("A.2");
/* nothing happens: preemption_goodness is 0 since B.1 has both
PROC_CHANGE_PENALTY and the += 1 from 'same mm'
*/
wake_up_sync("B.2");
schedule();
/* schedule selects A.2 instead of B.2 due to the += 1 from 'same mm'.
BUG: B.2 should replace B.1 on cpu1. The preemption_goodness is 1.
*/
IMHO obscure and very rare.
But I just found a bigger problem:
If wake_up_sync wakes up more than 1 process then cpus could remain in
cpu_idle() although processes are on the runqueue without cpus.
--
Manfred
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: wake_up vs. wake_up_sync
On Wed, Jun 27, 2001 at 02:57:43PM -0700, Scott Long wrote: > Does reschedule_idle() ever cause the current CPU to get scheduled? That > is, if someone calls wake_up() and wakes up a higher-priority process > could reschedule_idle() potentially immediately switch the current CPU > to that higher-priority process? No. reschedule_idle() never directly performs a 'task to task' context switch itself. Instead, it simply marks a currently running task to indicate that a reschedule is needed on that task's CPU. No task context switch will occur until schedule() is run on that CPU. -- Mike Kravetz [EMAIL PROTECTED] IBM Linux Technology Center - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: wake_up vs. wake_up_sync
Mike Kravetz wrote:
>
> On Wed, Jun 27, 2001 at 11:22:19PM +0200, Manfred Spraul wrote:
> > > Why would you want to prevent
> > > reschedule_idle()?
> > >
> > If one process runs, wakes up another process and _knows_ that it's
> > going to sleep immediately after the wake_up it doesn't need the
> > reschedule_idle: the current cpu will be idle soon, the scheduler
> > doesn't need to find another cpu for the woken up thread.
>
> I'm curious. How does the caller of wake_up_sync know that the
> current cpu will soon be idle. Does it assume that there are no
> other tasks on the runqueue waiting for a CPU? If there are other
> tasks on the runqueue, isn't it possible that another task has a
> higher goodness value than the task being awakened. In such a case,
> isn't is possible that the awakened task could sit on the runqueue
> (waiting for a CPU) while tasks with a lower goodness value are
> allowed to run?
>
I found one combination where that could happen:
process.thread
A.1: highest priority, runs on cpu0
B.1: lowest priority, runs on cpu1
A.2: another thread of process A, priority
PROC_CHANGE_PENALTY+PRIORITY(B.1)+1, sleeping.
B.2: same priority as A.2, sleeping, same process as B.1
A.1:
{
wake_up("A.2");
/* nothing happens: preemption_goodness is 0 since B.1 has both
PROC_CHANGE_PENALTY and the += 1 from 'same mm'
*/
wake_up_sync("B.2");
schedule();
/* schedule selects A.2 instead of B.2 due to the += 1 from 'same mm'.
BUG: B.2 should replace B.1 on cpu1. The preemption_goodness is 1.
*/
IMHO obscure and very rare.
But I just found a bigger problem:
If wake_up_sync wakes up more than 1 process then cpus could remain in
cpu_idle() although processes are on the runqueue without cpus.
--
Manfred
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: wake_up vs. wake_up_sync
Does reschedule_idle() ever cause the current CPU to get scheduled? That
is, if someone calls wake_up() and wakes up a higher-priority process
could reschedule_idle() potentially immediately switch the current CPU
to that higher-priority process?
Because this is NOT what I want to happen (it would produce a deadlock
in this particular situation). Having other CPUs get scheduled is ok,
but having the process that called wake_up() get kicked out would be
very bad. In that case I suppose I will have to use wake_up_sync().
Would the following be an appropriate solution?
{
wake_up_sync(>q);
/* Potential deadlock situation */
user_unlock(>lock);
/* Potential for deadlock has passed */
reschedule_idle();
}
Thanks,
Scott
Manfred Spraul wrote:
>
> > I'm having trouble understanding the difference between these.
> > Synchronous apparently causes try_to_wake_up() to NOT call
> > reschedule_idle() but I'm uncertain what reschedule_idle() is doing. I
> > assume it just looks for an idle CPU and makes that CPU reschedule.
> >
> > What is the purpose of wake_up_sync?
>
> Avoid the reschedule_idle() call - it's quite costly, and it could cause
> processes jumping from one cpu to another.
>
> > Why would you want to prevent
> > reschedule_idle()?
> >
> If one process runs, wakes up another process and _knows_ that it's
> going to sleep immediately after the wake_up it doesn't need the
> reschedule_idle: the current cpu will be idle soon, the scheduler
> doesn't need to find another cpu for the woken up thread.
>
> I think the pipe code is the only user of _sync right now - pipes cause
> an incredible amount of task switches.
>
> --
> Manfred
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: wake_up vs. wake_up_sync
On Wed, Jun 27, 2001 at 11:22:19PM +0200, Manfred Spraul wrote: > > Why would you want to prevent > > reschedule_idle()? > > > If one process runs, wakes up another process and _knows_ that it's > going to sleep immediately after the wake_up it doesn't need the > reschedule_idle: the current cpu will be idle soon, the scheduler > doesn't need to find another cpu for the woken up thread. I'm curious. How does the caller of wake_up_sync know that the current cpu will soon be idle. Does it assume that there are no other tasks on the runqueue waiting for a CPU? If there are other tasks on the runqueue, isn't it possible that another task has a higher goodness value than the task being awakened. In such a case, isn't is possible that the awakened task could sit on the runqueue (waiting for a CPU) while tasks with a lower goodness value are allowed to run? -- Mike Kravetz [EMAIL PROTECTED] IBM Linux Technology Center - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: wake_up vs. wake_up_sync
> I'm having trouble understanding the difference between these. > Synchronous apparently causes try_to_wake_up() to NOT call > reschedule_idle() but I'm uncertain what reschedule_idle() is doing. I > assume it just looks for an idle CPU and makes that CPU reschedule. > > What is the purpose of wake_up_sync? Avoid the reschedule_idle() call - it's quite costly, and it could cause processes jumping from one cpu to another. > Why would you want to prevent > reschedule_idle()? > If one process runs, wakes up another process and _knows_ that it's going to sleep immediately after the wake_up it doesn't need the reschedule_idle: the current cpu will be idle soon, the scheduler doesn't need to find another cpu for the woken up thread. I think the pipe code is the only user of _sync right now - pipes cause an incredible amount of task switches. -- Manfred - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
wake_up vs. wake_up_sync
I'm having trouble understanding the difference between these. Synchronous apparently causes try_to_wake_up() to NOT call reschedule_idle() but I'm uncertain what reschedule_idle() is doing. I assume it just looks for an idle CPU and makes that CPU reschedule. What is the purpose of wake_up_sync? Why would you want to prevent reschedule_idle()? Scott - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
wake_up vs. wake_up_sync
I'm having trouble understanding the difference between these. Synchronous apparently causes try_to_wake_up() to NOT call reschedule_idle() but I'm uncertain what reschedule_idle() is doing. I assume it just looks for an idle CPU and makes that CPU reschedule. What is the purpose of wake_up_sync? Why would you want to prevent reschedule_idle()? Scott - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: wake_up vs. wake_up_sync
I'm having trouble understanding the difference between these. Synchronous apparently causes try_to_wake_up() to NOT call reschedule_idle() but I'm uncertain what reschedule_idle() is doing. I assume it just looks for an idle CPU and makes that CPU reschedule. What is the purpose of wake_up_sync? Avoid the reschedule_idle() call - it's quite costly, and it could cause processes jumping from one cpu to another. Why would you want to prevent reschedule_idle()? If one process runs, wakes up another process and _knows_ that it's going to sleep immediately after the wake_up it doesn't need the reschedule_idle: the current cpu will be idle soon, the scheduler doesn't need to find another cpu for the woken up thread. I think the pipe code is the only user of _sync right now - pipes cause an incredible amount of task switches. -- Manfred - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: wake_up vs. wake_up_sync
On Wed, Jun 27, 2001 at 11:22:19PM +0200, Manfred Spraul wrote: Why would you want to prevent reschedule_idle()? If one process runs, wakes up another process and _knows_ that it's going to sleep immediately after the wake_up it doesn't need the reschedule_idle: the current cpu will be idle soon, the scheduler doesn't need to find another cpu for the woken up thread. I'm curious. How does the caller of wake_up_sync know that the current cpu will soon be idle. Does it assume that there are no other tasks on the runqueue waiting for a CPU? If there are other tasks on the runqueue, isn't it possible that another task has a higher goodness value than the task being awakened. In such a case, isn't is possible that the awakened task could sit on the runqueue (waiting for a CPU) while tasks with a lower goodness value are allowed to run? -- Mike Kravetz [EMAIL PROTECTED] IBM Linux Technology Center - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: wake_up vs. wake_up_sync
Does reschedule_idle() ever cause the current CPU to get scheduled? That
is, if someone calls wake_up() and wakes up a higher-priority process
could reschedule_idle() potentially immediately switch the current CPU
to that higher-priority process?
Because this is NOT what I want to happen (it would produce a deadlock
in this particular situation). Having other CPUs get scheduled is ok,
but having the process that called wake_up() get kicked out would be
very bad. In that case I suppose I will have to use wake_up_sync().
Would the following be an appropriate solution?
{
wake_up_sync(wq-q);
/* Potential deadlock situation */
user_unlock(wq-lock);
/* Potential for deadlock has passed */
reschedule_idle();
}
Thanks,
Scott
Manfred Spraul wrote:
I'm having trouble understanding the difference between these.
Synchronous apparently causes try_to_wake_up() to NOT call
reschedule_idle() but I'm uncertain what reschedule_idle() is doing. I
assume it just looks for an idle CPU and makes that CPU reschedule.
What is the purpose of wake_up_sync?
Avoid the reschedule_idle() call - it's quite costly, and it could cause
processes jumping from one cpu to another.
Why would you want to prevent
reschedule_idle()?
If one process runs, wakes up another process and _knows_ that it's
going to sleep immediately after the wake_up it doesn't need the
reschedule_idle: the current cpu will be idle soon, the scheduler
doesn't need to find another cpu for the woken up thread.
I think the pipe code is the only user of _sync right now - pipes cause
an incredible amount of task switches.
--
Manfred
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: wake_up vs. wake_up_sync
Mike Kravetz wrote:
On Wed, Jun 27, 2001 at 11:22:19PM +0200, Manfred Spraul wrote:
Why would you want to prevent
reschedule_idle()?
If one process runs, wakes up another process and _knows_ that it's
going to sleep immediately after the wake_up it doesn't need the
reschedule_idle: the current cpu will be idle soon, the scheduler
doesn't need to find another cpu for the woken up thread.
I'm curious. How does the caller of wake_up_sync know that the
current cpu will soon be idle. Does it assume that there are no
other tasks on the runqueue waiting for a CPU? If there are other
tasks on the runqueue, isn't it possible that another task has a
higher goodness value than the task being awakened. In such a case,
isn't is possible that the awakened task could sit on the runqueue
(waiting for a CPU) while tasks with a lower goodness value are
allowed to run?
I found one combination where that could happen:
process.thread
A.1: highest priority, runs on cpu0
B.1: lowest priority, runs on cpu1
A.2: another thread of process A, priority
PROC_CHANGE_PENALTY+PRIORITY(B.1)+1, sleeping.
B.2: same priority as A.2, sleeping, same process as B.1
A.1:
{
wake_up(A.2);
/* nothing happens: preemption_goodness is 0 since B.1 has both
PROC_CHANGE_PENALTY and the += 1 from 'same mm'
*/
wake_up_sync(B.2);
schedule();
/* schedule selects A.2 instead of B.2 due to the += 1 from 'same mm'.
BUG: B.2 should replace B.1 on cpu1. The preemption_goodness is 1.
*/
IMHO obscure and very rare.
But I just found a bigger problem:
If wake_up_sync wakes up more than 1 process then cpus could remain in
cpu_idle() although processes are on the runqueue without cpus.
--
Manfred
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: wake_up vs. wake_up_sync
Manfred,
Calling this a BUG is misleading. It is ok to be occasionally wrong
regarding the preemption priority as long as RT tasks are not involved.
This is due to the fact that PROC_CHANGE_PENALTIES are used, which already
provide for some priority inversion.
Hubertus Franke
email: [EMAIL PROTECTED]
(w) 914-945-2003(fax) 914-945-4425 TL: 862-2003
Manfred Spraul [EMAIL PROTECTED]@vger.kernel.org on 06/27/2001
06:41:29 PM
Sent by: [EMAIL PROTECTED]
To: Mike Kravetz [EMAIL PROTECTED]
cc: Scott Long [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: wake_up vs. wake_up_sync
Mike Kravetz wrote:
On Wed, Jun 27, 2001 at 11:22:19PM +0200, Manfred Spraul wrote:
Why would you want to prevent
reschedule_idle()?
If one process runs, wakes up another process and _knows_ that it's
going to sleep immediately after the wake_up it doesn't need the
reschedule_idle: the current cpu will be idle soon, the scheduler
doesn't need to find another cpu for the woken up thread.
I'm curious. How does the caller of wake_up_sync know that the
current cpu will soon be idle. Does it assume that there are no
other tasks on the runqueue waiting for a CPU? If there are other
tasks on the runqueue, isn't it possible that another task has a
higher goodness value than the task being awakened. In such a case,
isn't is possible that the awakened task could sit on the runqueue
(waiting for a CPU) while tasks with a lower goodness value are
allowed to run?
I found one combination where that could happen:
process.thread
A.1: highest priority, runs on cpu0
B.1: lowest priority, runs on cpu1
A.2: another thread of process A, priority
PROC_CHANGE_PENALTY+PRIORITY(B.1)+1, sleeping.
B.2: same priority as A.2, sleeping, same process as B.1
A.1:
{
wake_up(A.2);
/* nothing happens: preemption_goodness is 0 since B.1 has both
PROC_CHANGE_PENALTY and the += 1 from 'same mm'
*/
wake_up_sync(B.2);
schedule();
/* schedule selects A.2 instead of B.2 due to the += 1 from 'same mm'.
BUG: B.2 should replace B.1 on cpu1. The preemption_goodness is 1.
*/
IMHO obscure and very rare.
But I just found a bigger problem:
If wake_up_sync wakes up more than 1 process then cpus could remain in
cpu_idle() although processes are on the runqueue without cpus.
--
Manfred
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
