NPTL

NPTL

[Ni@m]

Hi!
I have a question about NPTL.
Are NPTL are still based on `clone` system call? Are NPTL threads are
"processes" internally?

Thanks!

RE: NPTL

[David Schwartz]

> Hi!
> I have a question about NPTL.
> Are NPTL are still based on `clone` system call?

Yes.

> Are NPTL threads are
> "processes" internally?

No. By definition, all the threads belong to a single process. NPTL threads
are based on KSEs (kernel scheduling entities). A non-threaded process is
also a KSE. A threaded process is more than one KSEs. All KSE are,
obviously, scheduled by the kernel.

> Thanks!

You're welcome.

DS

Re: NPTL

[Ni@m]

So I can say that in linux 'thread' == 'process'?

Is kernel routine 'kthread' creating a process?
I'm just thinking on this subject: if to create 'real threads' - will
it increase performance? Should I ever think in this way?
When I say 'real thread' - I mean the thread that doen't switch
context when it's starting to run.

On 7/12/07, David Schwartz <davids@webmaster.com> wrote:
>
> > Hi!
> > I have a question about NPTL.
> > Are NPTL are still based on `clone` system call?
>
> Yes.
>
> > Are NPTL threads are
> > "processes" internally?
>
> No. By definition, all the threads belong to a single process. NPTL threads
> are based on KSEs (kernel scheduling entities). A non-threaded process is
> also a KSE. A threaded process is more than one KSEs. All KSE are,
> obviously, scheduled by the kernel.
>
> > Thanks!
>
> You're welcome.
>
> DS
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

Re: NPTL

[Peter Zijlstra]

On Thu, 2007-07-12 at 15:37 +0300, Ni@m wrote:
> So I can say that in linux 'thread' == 'process'?

No, a process also contains an address space.

> Is kernel routine 'kthread' creating a process?

No, that is creating a schedule unit (task) without an address space.

> I'm just thinking on this subject: if to create 'real threads' - will
> it increase performance? Should I ever think in this way?
> When I say 'real thread' - I mean the thread that doen't switch
> context when it's starting to run.

Surely you need some context switch when switching between runnable
contexts.

BTW, please do _NOT_ top post!

Fwd: NPTL

[Ni@m]

>>BTW, please do _NOT_ top post!
sorry

>>No, a process also contains an address space.
Of course .. I ment they are _almoust_ similar.

>>No, that is creating a schedule unit (task) without an address space.
Ok, I've already found that in kernel code ... and correctly understood.

>>Surely you need some context switch when switching between runnable
contexts.
Hm. If the thread is running after it's sister or parent process - you
do not have to switich the process context. Is this done in kernel??

Sorry if my thought are idiotic .. I'm a newby and trying to
investigate the kernel.

Re: Fwd: NPTL

[Bernd Petrovitsch]

On Thu, 2007-07-12 at 15:58 +0300, Ni@m wrote:
[...]
> >>No, a process also contains an address space.
> Of course .. I ment they are _almoust_ similar.

Not really. A process has one or more threads, (virtual) memory, open
file descriptors, a uid, a gid and several other resources.

Historically there were only "processes". "Threads" were invented later
on so there is (usually) some confusion remaining  here .....

> >>No, that is creating a schedule unit (task) without an address space.
> Ok, I've already found that in kernel code ... and correctly understood.
> 
> >>Surely you need some context switch when switching between runnable
> contexts.
> Hm. If the thread is running after it's sister or parent process - you
> do not have to switich the process context. Is this done in kernel??

"switch process context" is misleading wording - "task switch" is better
(and "task" is usually the kernels view on a thread). You have at least
to store the registers of the old task somewhere and load the ones from
the new task.

> Sorry if my thought are idiotic .. I'm a newby and trying to
> investigate the kernel.

Hmm, you might invest in a book about operating systems to learn the
basic concepts.

	Bernd
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services

Re: Fwd: NPTL

[Lennart Sorensen]

On Thu, Jul 12, 2007 at 03:58:34PM +0300, Ni@m wrote:
> Of course .. I ment they are _almoust_ similar.

The lack of an address space seems to make them rather different too.  A
process contains address space, and one or more threads.  A thread is
hence a component of a process, but not really similar to a process
since it is just part of a process.

> Hm. If the thread is running after it's sister or parent process - you
> do not have to switich the process context. Is this done in kernel??

You are switching out cpu registers, stack, and such, even though you
are not changing address space, so you are doing a context switch.  The
cpu registers and state is the context.  Running multiple threads of a
single process in a row can avoid messing with the TLB and other address
space related things, but it still switches context.

--
Len Sorensen

Re: NPTL

[jimmy bahuleyan]

Ni@m wrote:
> So I can say that in linux 'thread' == 'process'?
> 

No. It's more like, in linux threads are visible to the kernel (unlike
in N:1 thread models, linux is 1:1). Threads are the basic unit of
scheduling.

A process can have >1 threads.

> Is kernel routine 'kthread' creating a process?
> I'm just thinking on this subject: if to create 'real threads' - will
> it increase performance? Should I ever think in this way?
> When I say 'real thread' - I mean the thread that doen't switch
> context when it's starting to run.
> 

What do you mean by context?

Each thread has it's own stack, registers, etc. which form it's context.
A process has more info like file descriptors, IPC resources, virtual
memory info. Between scheduling threads of the same process these stay same.

-jb
-- 
Tact is the art of making a point without making an enemy.

RE: NPTL

[David Schwartz]

> So I can say that in linux 'thread' == 'process'?

No. A process can have any number of threads.

> Is kernel routine 'kthread' creating a process?

No, since a process can have more than one thread.

> I'm just thinking on this subject: if to create 'real threads' - will
> it increase performance? Should I ever think in this way?
> When I say 'real thread' - I mean the thread that doen't switch
> context when it's starting to run.

I don't follow.

The kernel sometimes calls a KSE a 'process'. This is largely a legacy from
when there was a one-to-one correspondence between KSEs and processes.
However, this is no longer the case. In Linux, 'KSE' == 'thread'.

DS

NPTL

[Greg Weeks]

I saw the kernel support patch (TLS) a while back and ment to ask what 
state the gcc/glibc patches were in. Has either been picked up into the 
gnu projects yet? If they're close I might try building a toolchain and 
root file system with NPTL to try our test suite on.

Greg Weeks

Re: NPTL

[sjhill]

> I saw the kernel support patch (TLS) a while back and ment to ask what 
> state the gcc/glibc patches were in. Has either been picked up into the 
> gnu projects yet? If they're close I might try building a toolchain and 
> root file system with NPTL to try our test suite on.
> 
The kernel patch has not gone in and probably will not until a lot more
testing has been done. All of the changes to binutils, gcc and glibc
have been checked in and are available from HEAD of cvs for respective
repositories.

-Steve

Re: NPTL

[Daniel Jacobowitz]

On Fri, Apr 08, 2005 at 12:20:09PM -0500, sjhill@realitydiluted.com wrote:
> > I saw the kernel support patch (TLS) a while back and ment to ask what 
> > state the gcc/glibc patches were in. Has either been picked up into the 
> > gnu projects yet? If they're close I might try building a toolchain and 
> > root file system with NPTL to try our test suite on.
> > 
> The kernel patch has not gone in and probably will not until a lot more
> testing has been done.

Why do you say that?

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: NPTL

[sjhill]

> > The kernel patch has not gone in and probably will not until a lot more
> > testing has been done.
> 
> Why do you say that?
> 
I just made that assumption based on the fact that it is not in CVS
yet, at least it was not yesterday. Did I mis-speak?

-Steve

Re: NPTL

[Daniel Jacobowitz]

On Fri, Apr 08, 2005 at 12:23:35PM -0500, sjhill@realitydiluted.com wrote:
> > > The kernel patch has not gone in and probably will not until a lot more
> > > testing has been done.
> > 
> > Why do you say that?
> > 
> I just made that assumption based on the fact that it is not in CVS
> yet, at least it was not yesterday. Did I mis-speak?

I imagine it will go in exactly when Ralf and Maciej are ready for it
to :-)  It is extremely well tested already.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: NPTL

[Manish Lachwani]

sjhill@realitydiluted.com wrote:

>>I saw the kernel support patch (TLS) a while back and ment to ask what 
>>state the gcc/glibc patches were in. Has either been picked up into the 
>>gnu projects yet? If they're close I might try building a toolchain and 
>>root file system with NPTL to try our test suite on.
>>
>>    
>>
>The kernel patch has not gone in and probably will not until a lot more
>testing has been done. All of the changes to binutils, gcc and glibc
>have been checked in and are available from HEAD of cvs for respective
>repositories.
>
>-Steve
>
>  
>
Steve,

I thought the kernel patch was well tested by Daniel.

Thanks
Manish Lachwani