From: jesse <jessezx@yahoo.com>
To: Con Kolivas <kernel@kolivas.org>
Cc: Paulo Marques <pmarques@grupopie.com>, linux-kernel@vger.kernel.org
Subject: Re: Gurus, a silly question for preemptive behavior
Date: Tue, 21 Dec 2004 15:07:26 -0800 (PST) [thread overview]
Message-ID: <20041221230726.51621.qmail@web52604.mail.yahoo.com> (raw)
In-Reply-To: <41C89734.8020302@kolivas.org>
--- Con Kolivas <kernel@kolivas.org> wrote:
> jesse wrote:
> > Paulo:
> >
> > I already said in the messsage that my user
> space
> > application has a low nice priority, i set it to
> 10.
> > since my application has low priority compared to
> > other user space applications, it is supposed to
> be
> > interrupted. but it is not.
>
> If your task is better priority the scheduler will
> make it preempt the
> worse priority task. It sounds to me like you are
> complaining that the
> worse priority task is still getting cpu? If so, you
> misunderstand
> priority - it orders tasks according to priority
> giving lower latency
> and preemptive behaviour to the better task, and
> gives _more_ cpu but
> not all the cpu. The cpu must still be shared, but
> with more cpu
> distributed to the better priority task. If you want
> your better
> priority task to get _all_ the cpu you have to use
> real time scheduling.
>
> Cheers,
> Con
>
ok, Con, your explaining makes some sense to me , but
still not very well.
suppose I have five high process: A1, A2, A3, A4,
A5 all have nice = 0. and I also have a low priority
process B with nice = 10.
a) when process B is scheduled to run, it is given
a short time slot based on its priority, for example 5
secs. because at that point, A1/2/3/4/5 are not
started yet. B will get CPU and run at full speed.
b) at the end of time slot(5 secs), scheduler
finds higher priority A1/A2/A3/A4/A5 are ready,
scheduler will interrupt process B and starts to pick
a process from group A, even though B still needs CPU
cycle.
c)unfortunately, process A1/2/3/4/5 are so active,
thus process B should never get opportunity to run
again, in consequence, CPU Usage% of Process B should
be very Low.
However, The above theretic assumption is in
contrary to what i observed. in my LAB, the low
priority process B seems to hold the CPU forever and
Top command always shows Process B with a 90% CPU
usage.
If _more_ cpu but not _all_ the cpu are given to
Process A1/2/3/4/5, Process B shouldn't have a 90% CPU
usage.
Thus, i can't help asking why low priority process B
gets most CPU cycle.
thanks in advance.
jesse
next prev parent reply other threads:[~2004-12-21 23:07 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-12-21 2:43 jesse
2004-12-21 5:59 ` Con Kolivas
2004-12-21 18:32 ` jesse
2004-12-21 18:44 ` Paulo Marques
2004-12-21 19:03 ` jesse
2004-12-21 19:23 ` Paulo Marques
2004-12-21 21:35 ` Con Kolivas
2004-12-21 23:07 ` jesse [this message]
2004-12-22 2:16 ` Con Kolivas
2004-12-22 12:39 ` K.R. Foley
2004-12-26 19:30 ` Stephen Satchell
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=20041221230726.51621.qmail@web52604.mail.yahoo.com \
--to=jessezx@yahoo.com \
--cc=kernel@kolivas.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pmarques@grupopie.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®