Re: help with huge memory consumption??
- From: phil-news-nospam@xxxxxxxx
- Date: 9 Mar 2007 23:05:02 GMT
On 9 Mar 2007 05:33:51 -0800 David Schwartz <davids@xxxxxxxxxxxxx> wrote:
| On Mar 8, 6:41 am, Rainer Weikusat <rainer.weiku...@xxxxxxxxx> wrote:
|> "David Schwartz" <dav...@xxxxxxxxxxxxx> writes:
|
|> >> On a system that has only ever supported 1:1 threading as default
|> >> model, 'process creation' being much slower than 'thread creation'
|> >> would be a strong hint at a deficiency in the kernel. But reportedly, the
|> >> difference is negligible on Linux, so your assumption should be
|> >> wrong. And it is a strawman, except if you constrict yourself to a set
|> >> of real-world cases where the reason you try to shoot down actually
|> >> was the reason to use threads.
|
|> > This is a nonsensical reply.
|
|> It should be easy for you, then, to not only label it the way you
|> would like others to regard it, but to point out in detail which parts
|> of it are nonsensical for what reasons.
|
| Because thread creation is in no way analogous to process creation.
| There is no case where you think, "hmm, I could create a thread or a
| process, I wonder which is cheaper". So it's nonsensical to compare
| their costs.
They really are analogous, with just certain differences in the way
they get set up. You may, or may not, be sharding file descriptors,
for example. There's no reason we can't have a single system call
with a single implementation that simply lets the caller choose just
what is and is not shared between the resultant task elements. The
Linux clone() call is not too far from this.
|> > Thread creation is in no way analogous to process creation.
|
|> On Linux, using the default threading implementation, both are
|> ultimatively created by using the same system call (clone(2)) and
|> implemented with the same system mechanism (things the kernel sees as
|> 'tasks' by means of a struct task_struct), so they are not only
|> analogous but nearly identical.
|
| That they are done the same way does not make them analogous if the
| results are incomparable!
The results are comparable. Comparable does not imply identical.
They are, of course, different. But difference does not rule out
the concept of analogous.
I would use "not analogous" when comparing the fork() system call to
the unlink() system call, for example.
|> > Threads are reusable, processes are not.
|>
|> What is 'threads are reusable' supposed to mean?
|
| It means that you need to create a thread when, and only when, you
| need more threads than you have already created. However, you need to
| create a process not just when you need more processes but when you
| need different processes.
So there's a case where a need might require a process when a thread
cannot be used. That doesn't mean threads cannot be reseud FOR THEIR
purpose and processes cannot be reused FOR THEIR purposes.
| As a trivial example, consider a thread pool versus a 'fork after
| accept' server. The thread pool server will create some maximum number
| of threads over its life and will reuse them. The cost of a thread
| creation per client is effectively nearly zero. A 'fork after accept'
| server will create one process for each client it handles. The cost of
| a process creation is a per connection cost.
The existance of "thread after accept' and 'process pool servers' shows
this is all silly comparison.
| So it makes no sense whatsoever to compare the cost of one to the cost
| of the other. There is essentially no actual circumstance where one
| has the choice to do one or do the other the same number of times.
Such choices do exist at design time. Sometimes they even exist later.
There are things to deal with when making choices, but the choices can
be made.
--
|---------------------------------------/----------------------------------|
| Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
| first name lower case at ipal.net / spamtrap-2007-03-09-1657@xxxxxxxx |
|------------------------------------/-------------------------------------|
.
- References:
- help with huge memory consumption??
- From: Dan Miller
- Re: help with huge memory consumption??
- From: Michel Talon
- Re: help with huge memory consumption??
- From: phil-news-nospam
- Re: help with huge memory consumption??
- From: David Schwartz
- Re: help with huge memory consumption??
- From: phil-news-nospam
- Re: help with huge memory consumption??
- From: David Schwartz
- Re: help with huge memory consumption??
- From: Rainer Weikusat
- Re: help with huge memory consumption??
- From: David Schwartz
- Re: help with huge memory consumption??
- From: Rainer Weikusat
- Re: help with huge memory consumption??
- From: David Schwartz
- help with huge memory consumption??
- Prev by Date: initramfs + initrd
- Next by Date: Re: help with huge memory consumption??
- Previous by thread: Re: help with huge memory consumption??
- Next by thread: Re: help with huge memory consumption??
- Index(es):
Relevant Pages
|