thread memory size

David Schwartz wrote:
>
> Apparently.

An answer that was uncalled for.

You have the wrong definitions for the terms you are using and hence are
using the terms incorrectly, as explanation below.

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

ok so far so good.

>
>> "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.)


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.

regards

Jan

David Schwartz wrote:
> On Oct 6, 5:32 pm, Jan Helgesen <s....RemoveThis@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.

No it does not necessarily. Since you define vm as the processes address
space, you are basically talking about a processes or threads global
memory. So data stored in the processes memory is not by default shared.
It is shared in the sense that any thread can access it, but it is not
actually shared until two or more threads has a reference to that memory
area.

So memory allocated by, and referenced by, a threads local variables, is
not shared and does not need any synchronisation, because there is only
one thread that has actual access.

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

With the newly implemented version of the kernel, synchronisation and
locks have been dramatically reduced or improved. Meaning that such cost
is dramatically reduced. Further on a kernel can also reside across
several CPUs or cores, which means that the kernel can perform several
tasks at once.

Regarding the kernels concurrency, as far as I can remember, without
checking it right now, I seem to remember that when a thread performs a
system call. the call is not handled by a single kernel thread. Instead
the process thread starts the call, the arguments are copied from user
space to kernel space memory and then the thread changes its status from
user space thread to kernel thread (with the required change in address
registers and stack pointers, including its privilege level) and starts
performing the system call. And then vice verca when it is finished.

I think there are some pure kernel threads, that only opreate within the
kernel, that would at least be the the scheduler thread otherwise linux
would not be an pre-emptive scheduling kernel.

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

Almost right, message passing can also be used as a way to organise
programs or its components so that it will never need locking. For that
purpose, it can be used between threads in a processes confined memory
space.

And if the message passing implementation is transport neutral, it can
be used between both processes and threads, whether they are on the same
core, machine or not. That is an extra bonus, because it means that the
program does not have to be changed to be able to be moved or scaled.
The only thing that needs to be done, is to configure it differently so
that it uses more cores/processors or machines.

So even thought, from a purely technical point of view, message passing
within a single processes memory space, does not seem to make sense. It
does make sense when you look at message passing as a principle instead
of as a purely technical thing. As a principle it says, "send a message
from A to B in a certain format with the data attached". Call it rpc if
you want, but in this context its an extremely lightweight rpc, perhaps
almost on the level of function call lightweightness.

regards

Jan

David Schwartz wrote:
> On Oct 7, 1:36 am, Jan Helgesen <s... DeleteThis @nospam.com> wrote:
>
>> 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.
>
> Yes, it is. The "illusion of contiguous memory" *IS* the process'
> address space.

There is a not so subtle difference, which you don't seem to grasp.

- The illusion of contiguous memory, is called a processes address space.
- The technique that provides that illusion of contiguous memory is
called virtual memory.

Now a program can reserve an amount of virtual memory, but that is just
a way for the process to tell the kernel, from my entire address space,
can you allocate room on the mapping file for this amount of memory and
make it accessible through a range of memory addresses.

>
>> 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.
>
> Huh? It is precisely virtual memory that makes it possible for threads
> to share vm and process' not to. It is the kernel's memory management
> technique that makes it possible for each process to have its own view
> of memory -- its 'vm'.

Well, as stated above, you are basing your statment on the false
assumption that vm is the same as a processes address space. In that
context the answer is
- a systems memory mapping tehcnique has nothing to do with whether
memory can be shared between processes. that could be done even if the
system was running ms-dos.

What makes it possible to share memory between threads or processes is
that they share parts or all of their addresses spaces. Virtual memory
does not give processes or threads the ability to share address space,
thats the job of the clone, the shared memory allocation system call and
the scheduler.

>> These are the agreed upon definitions in the computer science world. but
>> you seems to have defined it differently.
>
> Google "shared vm" and take a look at the first dozen hits or so.

I did, here are the results. All of it mostly refers to sharing a java
virtual machine

http://www.google.com/search?client=opera&rls=en&q=shared+vm&sourceid=...ra&ie=u


I found one reference to a "processes sharing vm"

http://lkml.indiana.edu/hypermail/linux/kernel/0108.2/0253.html

But he confuses terms, in one sentence he uses processes and then he
mentions clone. Clone is to create threads, not processes.
So he seems to have the same misunderstanding of what virtual memory
actually is, as you do.


So there seems to mbe several hits for the similar things, but that
makes not sense, because sharing the vm struct (mm_struct) of the
kernel, actually implies we are talking about threads, not processes.
Because only threads can share the same address space, unless we are
talking about the IPC mechanism called System V Shared Memory or similar.

regards

Jan

On 10/06/2009 06:08 PM, Jan Helgesen wrote:
>
>
> Chris Friesen wrote:
>>
>> He has. Go back and read the information in this thread. The answer to
>> your question (as well as several corrections to your misconceptions and
>> the introduction of several issues which you likely haven't considered)
>> has already been covered.
>
> I disagree, the only answer he has given was where he stated that the
> task_struct is used by both a thread and a process.

No, he mentioned the amount of memory used by the kernel stack, as well
as the virtual address space, and a few other things.

> He says that there
> is no process structure. But a task_struct is a process structure by any
> other name.

No. A "process" has a specific definition in POSIX. Much of what makes
"process" separate from a "thread" is stored in other data structures
(like the mm_struct) that are separate from the task_struct. Thus each
kernel "task" gets a task struct. In the POSIX world, this basically
means that each thread gets a task struct. Since there is at least one
thread per process, each process requires at least one (but possibly
more) task structs. However, there is exactly one mm_struct per process.

> Such a structure contains process scheduler informations (
> state, priority, schedler_class etc), and also contains information such
> as policy, cpus_allowed, pid, ppid, cpu time and also a pointe to the
> stack), as he pointed out. But this structure takes up memory. And that
> is where my question was. This is memory which would not be occupied if
> the thread or process was not started.

You need to make a distinction between the information required for each
thread and the information required for the process as a whole. They're
stored in different places.

> So the fact that Linux shares that structure between both processes and
> threads, has very little implications for my question. My question was
> how big is that structure, and his answer had little to do with that.
> (a proper answer to those questions might be found in my last answer to
> Schwartz)

The size of that structure has little bearing on the overhead, as there
are other per-task and per-process overheads (the stack, primarily)
which are much larger.

Chris

On Oct 7, 2:05 am, Jan Helgesen <s....RemoveThis@nospam.com> wrote:

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

> Almost right, message passing can also be used as a way to organise
> programs or its components so that it will never need locking. For that
> purpose, it can be used between threads in a processes confined memory
> space.

You seem to have missed the words "for scalability" in the paragraph
above.

> So even thought, from a purely technical point of view, message passing
> within a single processes memory space, does not seem to make sense. It
> does make sense when you look at message passing as a principle instead
> of as a purely technical thing. As a principle it says, "send a message
> from A to B in a certain format with the data attached". Call it rpc if
> you want, but in this context its an extremely lightweight rpc, perhaps
> almost on the level of function call lightweightness.

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.

DS

On Oct 7, 2:40 am, Jan Helgesen <s... RemoveThis @nospam.com> wrote:
> David Schwartz wrote:
> > On Oct 7, 1:36 am, Jan Helgesen <s... RemoveThis @nospam.com> wrote:

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

> > Yes, it is. The "illusion of contiguous memory" *IS* the process'
> > address space.

> There is a not so subtle difference, which you don't seem to grasp.
>
> - The illusion of contiguous memory, is called a processes address space.
> - The technique that provides that illusion of contiguous memory is
> called virtual memory.

The technique is called virtual memory, but so is the result of using
that technique. Virtual memory, the technique, provides virtual
memory, the service and even virtual memory, the type of memory
provided by the technique.

> Now a program can reserve an amount of virtual memory, but that is just
> a way for the process to tell the kernel, from my entire address space,
> can you allocate room on the mapping file for this amount of memory and
> make it accessible through a range of memory addresses.

Right, and both virtual memory (in the sense of address space) and
virtual memory (the type of memory) are reserved. Inside the OS, this
actually creates two reservations.

> > Huh? It is precisely virtual memory that makes it possible for threads
> > to share vm and process' not to. It is the kernel's memory management
> > technique that makes it possible for each process to have its own view
> > of memory -- its 'vm'.

> Well, as stated above, you are basing your statment on the false
> assumption that vm is the same as a processes address space. In that
> context the answer is
> - a systems memory mapping tehcnique has nothing to do with whether
> memory can be shared between processes. that could be done even if the
> system was running ms-dos.

That a nonsensical argument. We're not talking about how other systems
do things but about how Linux systems do things. That it could be done
some other way someplace else is irrelevant.

> What makes it possible to share memory between threads or processes is
> that they share parts or all of their addresses spaces. Virtual memory
> does not give processes or threads the ability to share address space,
> thats the job of the clone, the shared memory allocation system call and
> the scheduler.

It's precisely virtual memory that, on the type of system we're
talking about, makes it possible for processes and threads to share
address space. It's the fact that the kernel uses virtual memory as a
technique to provide each task its own view of memory, or a shared
view of memory, that can contain mappings to the same physical pages
or not.

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

> > Google "shared vm" and take a look at the first dozen hits or so.

> I did, here are the results. All of it mostly refers to sharing a java
> virtual machine
>
> http://www.google.com/search?client=opera&rls=en&q=shared+vm&sourceid...
>
> I found one reference to a "processes sharing vm"
>
> http://lkml.indiana.edu/hypermail/linux/kernel/0108.2/0253.html
>
> But he confuses terms, in one sentence he uses processes and then he
> mentions clone. Clone is to create threads, not processes.

Clone can create threads, processes, and even things in-between.
Technically, 'clone' creates a KSE. It may or may not share a vm, file
table, and other things with the creating task.

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

Perhaps everyone but you has this misunderstanding.

DS

David Schwartz wrote:
>> So he seems to have the same misunderstanding of what virtual memory
>> actually is, as you do.
>
> Perhaps everyone but you has this misunderstanding.

Until you can come up with any references from credible source that
supports your statement, I will stick to Tannenbaum and other have
defined it to be. And according to their definitions, your understanding
is wrong..

regards

Jan

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.

regards

Jan

On Oct 7, 10:44 pm, Jan Helgesen <s....RemoveThis@nospam.com> wrote:

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

This is a serious misunderstanding on your part. They *do* need to
share it and lock it. The reason for the message passing is precisely
to allow the threads to easily share and lock data.

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

It would help if you showed some indication that you understood what I
was saying.

DS

On Oct 8, 11:10 pm, Jan Helgesen <s... DeleteThis @nospam.com> wrote:

> David Schwartz wrote:

> Actually, after reading it agains I see where your misunderstanding is.

> > This is a serious misunderstanding on your part. They *do* need to
> > share it and lock it. The reason for the message passing is precisely
> > to allow the threads to easily share and lock data.

> I was not not talking about message passing, I was just talking about
> threads that share the same memory address space.

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

> If there is a message passing mechanism involved then mostly yes. In
> many implementation there would need to be some synchronisation within
> the message passing implementation.

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.

> Mind you, there are such concurrency structures that can be implemented
> without locks, they are called lock-free implementations and are usually
> based on state machines.

That changes nothing. Lock-free synchronization is still
synchronization.

> But, the program is not required to focus on that any more, because its
> all in the library instead of in the program code.

> And that is my entire point, that when one uses a simple mechanism as
> message passing, synchronisation is left to the library, not the
> program. The program code does not need to worry about it, since data is
> not shared by the programs threads, but just by the messaging library
> for a brief nanosecond, once. That's quite a simple model.

Of course.

> So this reduced concurrency control requirement is dependent on two new
> aspects. Letting the message passing library deal with it the
> concurrency, since it is easy to test and verify. And structuring the
> program differently so that it utilises message passing and enables
> massive parallelism instead of the sequential programming model of today.

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

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

DS

On Oct 6, 5:17 am, Jan Helgesen <s....RemoveThis@nospam.com> wrote:

> The problem with shared resource are all the different access patterns,
> and the difficulty with mapping out all patterns so as to make sure you
> have covered every angle and every combination of access to the data.

Nonsense. You can trivially implement something like message passing
and use that. You cannot possibly make a coherent argument that using
"X and never, ever Y" is easier than using "X or Y, whichever works
best for each instance".

> With message passing you don't have to do all of that because because
> the model is quite simple, one or more readers at one end and one or
> more writers at the other end. The data is then copied from the sender
> to the receiver, so the only contention is possibly in the queue
> algorithm, which is quite simple and which you use a quality queue
> library for. That is quite an easy model to handle. So that means that
> Joe average programmer, only have to deal with the interfaces of the
> queue, not the details of the synchronisation of the queue. This way all
> synchronisation is removed from the programmers responsibility.

You mean with message passing, you *can't* do that even if you want
to. That is a *cost* that only makes sense to pay if there's some
corresponding *benefit*.

The benefit is simple -- you don't have to share memory. And that is
the *only* benefit to prohibiting the use of other synchronization
mechanisms.

I cannot understand why you cannot understand this.

DS

On Oct 9, 12:02 am, Jan Helgesen <s... RemoveThis @nospam.com> wrote:

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

You are still confused. "Lock-free" is a misnomer. There are still
locks, they are just not locks that block. For example, the primitive
lock-free algorithms are made out of contain atomic 'compare and
replace' operations or atomic 'swap' operations. These operations
internally contain locks, for example, they lock cache lines.

But I appreciate your attempt at catching me in a minor "gotcha" so as
to waste time and avoid the major issues.

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

But this is totally and utterly false. You need *precisely* the same
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.

This is a misunderstanding you keep repeating and repeating. It is
false. Message passing requires precisely the same locking as every
other form of IPC. The advantage of message passing has *nothing* to
do with the fact that message passing is somehow incredibly efficient
or doesn't require locks or concurrency that other forms of IPC
require.

The advantage of message passing, from a scalability and performance
standpoint, is one thing and one thing only -- you do not have to
share address space.

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

I understand what you're saying, it's simply completely incorrect. And
when I try to point out your misunderstandings, you try to play
"gotcha" on minor and irrelevant issues while you insist on missing
the forest.

The forest is this -- message passing is inefficient. The reason
people use it for performance and scalability is because if you limit
yourself to message passing only, you can get the concurrency of
threads without the inherent performance penalties of threads.

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

Right, the advantage of message passing is that it doesn't have the
limitations of shared memory. So it would be an absolutely mind-
bogglingly stupid thing to do to build a message passing system on top
of shared memory threads. You would suffer all the disadvantages of
threads and get absolutely *none* of the benefits. *Nobody* with any
brains would do that unless performance and scalability were the
lowest priorities. If you're talking about scaling to thousands of
cores and using message passing, you would *NEVER* do it with threads.

DS

On Oct 9, 12:11 am, Jan Helgesen <s....DeleteThis@nospam.com> wrote:

> > The benefit is simple -- you don't have to share memory. And that is
> > the *only* benefit to prohibiting the use of other synchronization
> > mechanisms.

> Exactly

So why are you asking about threads which do have to share memory?

> and that is the one benefit I am talking about. It allows
> massive parallelisation of code, which is an enourmous benefit. That
> benefit can be utilised when computers move to more and more cores per
> processors, instead of the old game that was about more and more
> kilo/mega/giga hertz.

Yes, if and only if you *don't* use shared memory. So why are you
asking about threads?

DS