Re: help with huge memory consumption??



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 |
|------------------------------------/-------------------------------------|
.



Relevant Pages

  • Re: CP/M 2009 (was: Re: CP/M Source)
    ... Compare the hold MS still has compared with ... a free Linux/BSD/whatever distribution on disks, ... the cost of M$ is levied before the product is ... I have an EeePC that runs Linux and it came that way, ...
    (comp.os.cpm)
  • Re: P4 Xeon compatibility with 5.0.5
    ... but isn't this an expensive solution based on an annual subscription ... > compare with the cost of equivalent commercial Intel-based Unix products? ... I was refuting Brian's assertion the Linux is too ...
    (comp.unix.sco.misc)
  • Re: Why I dumped Linux and Went Back to Microsoft
    ... > which keeps the cost of the whole computer package lower than a MAC. ... Why do you compare with a MAC when we are talking about Linux on intel ... I think BG would very much mind if you buy Linux. ...
    (alt.os.linux.suse)
  • Re: Quad Core PC for less than a Mac Mini
    ... A meaningless one when compared to computers. ... Cars are quite easy for a friend of mine to assemble, ... compare equals. ... home is an example of a cost avoidance of eating out. ...
    (comp.sys.mac.advocacy)
  • Re: help with huge memory consumption??
    ... Given a parallel task that can be done with threads, ... Just because design issues are different (they are for lots of choices ... | You cannot take two completely different programs and compare them by ... | looking at the cost of one operation that one does against some other ...
    (comp.os.linux.development.system)

Quantcast