public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Anders Peter Fugmann <afu@fugmann.dhs.org>
To: "Nicolae P. Costescu" <nick@strongholdtech.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: CPU scheduler question: processes created faster than  destroyed?
Date: Thu, 18 Apr 2002 23:20:31 +0200	[thread overview]
Message-ID: <3CBF389F.7010807@fugmann.dhs.org> (raw)
In-Reply-To: <4.3.2.7.2.20020418153151.019a98e0@mail.qrts.com>

Nicolae P. Costescu wrote:
> At the point where the server replied to the client, the client 
> disconnects and is ready to send another message to the master server, 
> which will cause another 4 forks, etc.

So, your clients are contacting the server repeatably...

First there is something in your desctiption that was not entirely clear.
After the server has received a request and has spawned four processes, does it sleep while
waiting for data?

If yes, the server would get a high counter. This means that the "dynamic proirity" of the server
process would be higher than the spawned processes, and hence be able to starve the child processes
for a small ammount of time. Therefore it is able to send the answer back to the client and receive a
new request before any of the first spawned processes has terminated. Also the new spawned children will
possibly have a higher "dynamic priority" (Really hate to use this term) than the first spawned processes.

Try and understand the line:
     p->counter = (p->counter >> 1) + NICE_TO_TICKS(p->nice);
in kernel/sched.c#624 - 2.4.18, especially when a process is sleeping.

 > Is this just bad design on our part, or is there something in the CPU scheduler that leads to this
 > behavior - where processes are started quicker than they die?

Well. If my assumptions are correct it is both. The scheduler works in this way, but
that should not harm your application (it actually speed it up), but you might want
to redesign your application to avoid too many proccesse being spawned.

I would suggest one of two ways to do this.

1) Let the server wait for the spawned processes to die, before accepting new requests.
The draw back migh be that it will slow down the server process a bit.

2) Dont spawn new processes all the time. Spawn the four needed processes once and for all,
and insted of terminating after proccessing, let them wait for a new command (acting just like your server).

Hope it helps.
Anders Fugmann










  reply	other threads:[~2002-04-18 21:20 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-04-18 20:06 CPU scheduler question: processes created faster than destroyed? Nicolae P. Costescu
2002-04-18 21:20 ` Anders Peter Fugmann [this message]
2002-04-19  5:57   ` Nicolae P. Costescu

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=3CBF389F.7010807@fugmann.dhs.org \
    --to=afu@fugmann.dhs.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nick@strongholdtech.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