That's your merciful assumption :->. I am fairly convinced that this
is part of the stern wave of this

http://www.barrelfish.org/

Rainer Weikusat wrote:
That's your merciful assumption :->. I am fairly convinced that this
is part of the stern wave of this

http://www.barrelfish.org/


You lost me now, but thats ok.

Because I found an article stating how threads and kernel memory
work. Linux don't have its own threads structure its only got
something called a task_structure, which is treated equally to
processes by the scheduler. The only difference is that the task
structure is part of an existing process, so the task structure does
not need to contain too much data, as all the rest is properly set
up by the process structures.

(It interesting how I was only asking how much kernel memory linux
requires per thread.

And as any person discussing on Usenet, I will
argue my case. But for some reason this discussion has shifted into a
completely new theme, which is some sort of bashing against what you
don't like or believe in.

I have no problems with what you believe in
or like. I only ask that you answer my questions in a serious matter,
instead of trying to belittle things that you don't agree with. The
world was once flat...

Ok, so if you think I have misunderstood it all and I barely have any
knowledge about anything, I will give you a chance to explain,
preferably in different wording than you already have, what you think
I am misunderstanding so completely.

Jan Helgesen <spam at (no spam) nospam.com> writes:
Ok, so if you think I have misunderstood it all and I barely have any
knowledge about anything, I will give you a chance to explain,
preferably in different wording than you already have, what you think
I am misunderstanding so completely.

Since you have again sent me an e-mail from your fake address and have
(apparently) completely ignored the other parts of my posting, namely,
the technical explanations, as well, why would I repeat myself? You
aren't listening, anyway.

Rainer Weikusat wrote:
Jan Helgesen <spam at (no spam) nospam.com> writes:
Ok, so if you think I have misunderstood it all and I barely have any
knowledge about anything, I will give you a chance to explain,
preferably in different wording than you already have, what you think
I am misunderstanding so completely.

Since you have again sent me an e-mail from your fake address and have
(apparently) completely ignored the other parts of my posting, namely,
the technical explanations, as well, why would I repeat myself? You
aren't listening, anyway.

That's just an pitiful excuse. If you have a compelling argument then
spit it out.

3) Shared vm has a high performance cost.

what cost is that, and the high performance cost is compared to what?

The whole point of message passing for scalability is that you don't
have to use a shared vm. You can distribute your large operation over
multiple memory domains. Shared vm among thousands of cores make
absolutely no sense at all for the foreseeable future.

I am having problems understanding what you are saying here.

First off, when you say vm, you mean virtual memory, right?
Wikipedia defines virtual memory as:

"Virtual memory is a computer system technique which gives an
application program the impression that it has contiguous working memory
(an address space), while in fact it may be physically fragmented and
may even overflow on to disk storage."

So virtual memory is not a process or programs complete address space,

it is the technique that the kernel uses to let the process believe it
has got a contiguous address space, agreed?

So the question is then, when you say "shared vm", do you mean

1) shared memory (as in the IPC technique called System V Shared Memory)

2) the processes complete address space

I will get back to answering the other part of the post after you have
given me an answer.

Ok, so here is the confusion. Do you have any proof to back up that
claim. I have been doing computers for 20 years and all my books on
operating systems and programming defines vm as a kernel memory
management technique to create the illusion of contiguous memory to a
process. Which is not another word for the process address space, shared
or non-shared.

The processes address space is the memory available to the program, i.e.
process or threads. By definition that memory is shared among all
threads, otherwise it would not be a thread, it would be different
processes. Virtual memory on the other hand is as I have already stated,
a kernel memory management technique.

These are the agreed upon definitions in the computer science world. but
you seems to have defined it differently.

On Oct 6, 5:32 pm, Jan Helgesen <s... at (no spam) nospam.com> wrote:

3) Shared vm has a high performance cost.

what cost is that, and the high performance cost is compared to what?

Anything that manipulates the vm has to be synchronized. Consider, for
example, opening a file. Consider mapping a new region of memory.
Also, since they have to be in the same SMP region, they typically
have to all be talking to a single kernel. So many kernel operations
will wind up imposing some kind of synchronization cost.

The whole point of message passing for scalability is that you don't
have to use a shared vm. You can distribute your large operation over
multiple memory domains. Shared vm among thousands of cores make
absolutely no sense at all for the foreseeable future.

Apparently.

First off, when you say vm, you mean virtual memory, right?
Wikipedia defines virtual memory as:

Yes.

"Virtual memory is a computer system technique which gives an
application program the impression that it has contiguous working memory
(an address space), while in fact it may be physically fragmented and
may even overflow on to disk storage."

So virtual memory is not a process or programs complete address space,

Umm, yes it is. The process or program's complete address space is its
vm. (Perhaps you're not familiar with this usage, but it's very
common.)

So he seems to have the same misunderstanding of what virtual memory
actually is, as you do.

Perhaps everyone but you has this misunderstanding.

It makes perfect sense to use message passing within a single vm. What
makes no sense, however, is to design a system that uses message
passing for scalability using threads which share their vm.

David Schwartz wrote:

It makes perfect sense to use message passing within a single vm. What
makes no sense, however, is to design a system that uses message
passing for scalability using threads which share their vm.

As I have said it allows threads to access data without needing to share
it and lock it.

If you don't have any more compelling arguments than
repeating what you are saying. There is no point in continuing the
discussion.

David Schwartz wrote:

Huh? Now you've lost me. We were talking about architectures that use
message passing for scalability.

That is true. But your claim was that one always needs locking. which I
explained one does not always need.

There would always have to be. The scalability advantage of message
passing does not come from the message passing itself being somehow
incredibly efficient. In fact, in general message passing is less
efficient than other types of IPC.

I have have never said that the implementation of the message passing
makes it more efficient. I have said that the scalability advantage
comes from the fact that one can parallelise the program without the
need for locking.

Hence it makes it more efficient in the fact that more
work can be done in parallel, possibly massively parallel. That an
advantage that is diminishing by the day, with sequential programming
practice of today.

I still see no evidence you have understood anything I'm saying.

dont be rude, you dont seem to understand what I am saying either so
there is no need for that kind attitude, it does not help the discussion.

You seem to completely misunderstand the entire point of going to the
trouble of using message passing. You erroneously think this somehow
makes design and implementation easier, when in fact it makes design
and implementation harder. (Why? Because you can always make any IPC
look like message passing. But when you commit to using message
passing *FOR* *SCALABILITY* you lose the ability to use other forms of
IPC such as shared memory.)

The possibility of scalability does not come in one form only. Shared
memory is one answer, but it has its limitations. Message passing is
another, which addressed many of the limitations of shared memory, with
respect to concurrency. Other than that see my answers above.