From: "Hubertus Franke" <frankeh@us.ibm.com>
To: "Adam J. Richter" <adam@yggdrasil.com>
Cc: lse-tech@lists.sourceforge.net, linux-kernel@vger.kernel.org
Subject: Re: PATCH(?): linux-2.4.4-pre2: fork should run child first
Date: Fri, 13 Apr 2001 12:28:58 -0400 [thread overview]
Message-ID: <OF69F0F3AE.1E1ACFE0-ON85256A2D.0055CD5B@pok.ibm.com> (raw)
First you are wrong by assuming that setting current->counter=0
will guarantee that the child runs first. In an SMP it only means
that this might initiate another recalculate and could run from
there in parallel with the child.
Actually quickly looking at the source code here.
You don't have to call schedule() at all.
A bit further down wake_up_process(p) is called, which in turn
calls reschedule_idle(p). Hence we don't have to call schedule.
If one satisfies the conditions:
(preemption_goodness(current,p,p->processor) > 1) then the child should
run.
[ with (child==p) and (parent==current) ].
This is for the uniprocessor system. In the SMP both could continue
to run. Looking at goodness computation, since p->mm == current->mm,
p->nice == current->nice and p->processor == current->processor,
all what matters is the difference in the counter values.
My proposed patch always yield 1, which ofcourse doesn't have the desired
effect.
Here is a patch that always yields a diff of 2. However for odd number of
current->counter it looses a token between the two.
{
long parcnt = current->counter;
p->counter = (parcnt+((parcnt&1)?1:2)) >> 1;
parcnt >>= 1;
if (parcnt>0) {
current->counter = 0;
current->need_resched = 1;
} else {
current->counter = parcnt - 1;
}
There is the other view that I should not loose a token.
In that case the following code will add a token in the odd counter case.
I think that this is preferrable over the first solution.
p->counter = (current->counter+3)>>1;
current->counter = (current->counter >> 1) - 1;
if (current->counter <= 0) {
current->counter = 0;
current->need_resched = 1;
}
Hubertus Franke
Enterprise Linux Group (Mgr), Linux Technology Center (Member Scalability)
, OS-PIC (Chair)
email: frankeh@us.ibm.com
(w) 914-945-2003 (fax) 914-945-4425 TL: 862-2003
"Adam J. Richter" <adam@yggdrasil.com> on 04/12/2001 08:42:12 PM
To: Hubertus Franke/Watson/IBM@IBMUS
cc:
Subject: Re: PATCH(?): linux-2.4.4-pre2: fork should run child first
> p->counter = (current->counter + 1) >> 1;
> current->counter = (current->counter - 1) >> 1;
> schedule();
I don't have time to try this right now and I'm not sure
what locks are held at that point in the code or whether schedule()
will actually schedule a different process if the current one
has current->counter > 0 (even if current->need_resched is set and
even if another process has a higher proc->counter value).
Even if it did work, your code is more complex and makes it
less likely that the child will reach exec() before the parent
runs again. So, I am not sure I would see the advantage if it did work.
Adam J. Richter __ ______________ 4880 Stevens Creek Blvd, Suite
104
adam@yggdrasil.com \ / San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l United States of America
fax +1 408 261-6631 "Free Software For The Rest Of Us."
next reply other threads:[~2001-04-13 16:35 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-04-13 16:28 Hubertus Franke [this message]
-- strict thread matches above, loose matches on Subject: below --
2001-04-14 16:11 Adam J. Richter
2001-04-14 7:58 Adam J. Richter
2001-04-14 8:42 ` Michael O'Reilly
2001-04-14 9:00 ` Linus Torvalds
2001-04-14 15:06 ` Rik van Riel
2001-04-14 2:45 Adam J. Richter
2001-04-13 23:51 Adam J. Richter
2001-04-14 1:54 ` John Fremlin
2001-04-14 2:29 ` Linus Torvalds
2001-04-14 2:51 ` Alexander Viro
2001-04-14 2:52 ` Ulrich Drepper
2001-04-12 19:45 Adam J. Richter
2001-04-12 19:15 Adam J. Richter
2001-04-12 13:44 Hubertus Franke
2001-04-12 8:55 Adam J. Richter
2001-04-12 12:38 ` Horst von Brand
2001-04-17 9:15 ` Éric Brunet
2001-04-17 14:26 ` Jesse Pollard
2001-04-17 15:32 ` Éric Brunet
2001-04-13 21:08 ` John Fremlin
2001-04-14 3:53 ` Rik van Riel
2001-04-14 4:40 ` Linus Torvalds
2001-04-14 13:35 ` Rik van Riel
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=OF69F0F3AE.1E1ACFE0-ON85256A2D.0055CD5B@pok.ibm.com \
--to=frankeh@us.ibm.com \
--cc=adam@yggdrasil.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lse-tech@lists.sourceforge.net \
/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®