NPTL

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

[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

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

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!

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