[PATCH] quieten OOM killer noise

[PATCH] quieten OOM killer noise

[Anton Blanchard]

We now print statistics when invoking the OOM killer, however this
information is not rate limited and you can get into situations where
the console is continually spammed.

For example, when a task is exiting the OOM killer will simply return
(waiting for that task to exit and clear up memory). If the VM
continually calls back into the OOM killer we get thousands of copies of
show_mem() on the console.

Use printk_ratelimit() to quieten it.

Signed-off-by: Anton Blanchard <anton@samba.org>

Index: foobar2/mm/oom_kill.c
===================================================================
--- foobar2.orig/mm/oom_kill.c	2005-07-02 15:56:13.000000000 +1000
+++ foobar2/mm/oom_kill.c	2005-07-04 01:38:59.474324542 +1000
@@ -258,9 +258,11 @@
 	struct mm_struct *mm = NULL;
 	task_t * p;
 
-	printk("oom-killer: gfp_mask=0x%x\n", gfp_mask);
-	/* print memory stats */
-	show_mem();
+	if (printk_ratelimit()) {
+		printk("oom-killer: gfp_mask=0x%x\n", gfp_mask);
+		/* print memory stats */
+		show_mem();
+	}
 
 	read_lock(&tasklist_lock);
 retry:

Re: [PATCH] quieten OOM killer noise

[Daniel Walker]

Why not just remove the printk's when DEBUG_KERNEL is off. The problem
that I've found is that the latency in the system sky rockets when OOM
triggers. It's due to the excessive printk usage. 

I'm sure it's not ifdef'ed for a reason , but it would be nice to have an
easy way to silence it.

Daniel

On Sun, 24 Jul 2005, Anton Blanchard wrote:

> 
> We now print statistics when invoking the OOM killer, however this
> information is not rate limited and you can get into situations where
> the console is continually spammed.
> 
> For example, when a task is exiting the OOM killer will simply return
> (waiting for that task to exit and clear up memory). If the VM
> continually calls back into the OOM killer we get thousands of copies of
> show_mem() on the console.
> 
> Use printk_ratelimit() to quieten it.
> 
> Signed-off-by: Anton Blanchard <anton@samba.org>
> 
> Index: foobar2/mm/oom_kill.c
> ===================================================================
> --- foobar2.orig/mm/oom_kill.c	2005-07-02 15:56:13.000000000 +1000
> +++ foobar2/mm/oom_kill.c	2005-07-04 01:38:59.474324542 +1000
> @@ -258,9 +258,11 @@
>  	struct mm_struct *mm = NULL;
>  	task_t * p;
>  
> -	printk("oom-killer: gfp_mask=0x%x\n", gfp_mask);
> -	/* print memory stats */
> -	show_mem();
> +	if (printk_ratelimit()) {
> +		printk("oom-killer: gfp_mask=0x%x\n", gfp_mask);
> +		/* print memory stats */
> +		show_mem();
> +	}
>  
>  	read_lock(&tasklist_lock);
>  retry:
> -
> 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: [PATCH] quieten OOM killer noise

[Anton Blanchard]

Hi,

> Why not just remove the printk's when DEBUG_KERNEL is off. The problem
> that I've found is that the latency in the system sky rockets when OOM
> triggers. It's due to the excessive printk usage. 
> 
> I'm sure it's not ifdef'ed for a reason , but it would be nice to have an
> easy way to silence it.

We've had customer situations where that information would have been
very useful. Also DEBUG_KERNEL is enabled on some distros so it wouldnt
help there.

Id suggest adding a printk level to the printks in mm/oom-kill.c and
using /proc/sys/kernel/printk to silence them.

Anton

Re: [PATCH] quieten OOM killer noise

[Daniel Walker]

On Mon, 4 Jul 2005, Anton Blanchard wrote:

> 
> Hi,
> 
> > Why not just remove the printk's when DEBUG_KERNEL is off. The problem
> > that I've found is that the latency in the system sky rockets when OOM
> > triggers. It's due to the excessive printk usage. 
> > 
> > I'm sure it's not ifdef'ed for a reason , but it would be nice to have an
> > easy way to silence it.
> 
> We've had customer situations where that information would have been
> very useful. Also DEBUG_KERNEL is enabled on some distros so it wouldnt
> help there.
> 
> Id suggest adding a printk level to the printks in mm/oom-kill.c and
> using /proc/sys/kernel/printk to silence them.

The latency problem stems from running printk, so I'm not sure that 
silencing them in this way would help . We could add a debug option just 
for this ? I'm sure OOM has other debugging output . CONFIG_OOM, and 
CONFIG_DEBUG_OOM .

Daniel  

RE: [PATCH] quieten OOM killer noise

[Al Boldi]

Anton Blanchard wrote: {
Id suggest adding a printk level to the printks in mm/oom-kill.c and using
/proc/sys/kernel/printk to silence them.
}

Good option!

Also, why is OOM-killer needed when overcommit is disabled?

Al

Re: [PATCH] quieten OOM killer noise

[Paul Jackson]

Anton wrote:
> We've had customer situations where that information would have been
> very useful.

I haven't looked closely, but when I provoked the oom killer last week
a few times while working on something else, I did notice that the
printk's that came out were a page or two, per kill.  Apparently it
is the arch-specific show_mem() routine that was so verbose - this
was on an ia64 SN2.

Do we really need that lengthy an oom printk?  If the other arch's
tend to be a little more terse, then I guess you could catalog my
complaint as a "personal problem" or at least an "arch problem."

In support of this ratelimiting, the other call from main line kernel
code to show_mem(), after the __alloc_pages() message:

	 page allocation failure. order:%d, mode:0x%x

is already ratelimited.  Seems like a good idea.

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@sgi.com> 1.925.600.0401

Thread_Id

[RVK]

Can anyone suggest me how to get the threadId using 2.6.x kernels. 
pthread_self() does not work and returns some -ve integer.

thanks
rvk

Re: Thread_Id

[Arjan van de Ven]

On Tue, 2005-07-05 at 17:45 +0530, RVK wrote:
> Can anyone suggest me how to get the threadId using 2.6.x kernels. 
> pthread_self() does not work and returns some -ve integer.

NAME
       pthread_self - get the calling thread ID

SYNOPSIS
       #include <pthread.h>

       pthread_t pthread_self(void);

DESCRIPTION
       The pthread_self() function shall return the thread ID of the
calling thread.




pthread_self() works just fine for me. But... what makes you think a
"negative" value is a failure? What interpretation are you giving to
thread ID that negative woudl be wrong? A pthreads thread ID is just a
cookie you only can use to give back to the pthread library functions in
places where it's needed...

Re: Thread_Id

[Benedikt Spranger]

Hi,
> Can anyone suggest me how to get the threadId using 2.6.x kernels. 
> pthread_self() does not work and returns some -ve integer.

Let me guess: You are looking for get_tid() :-)

Bene

Re: Thread_Id

[RVK]

You are right Ben....gettid() will do for me. Previously for 2.4.x 
(2.4.18)thread libraries I normally was using pthread_self().

Raghu

Benedikt Spranger wrote:

>Hi,
>  
>
>>Can anyone suggest me how to get the threadId using 2.6.x kernels.
>>pthread_self() does not work and returns some -ve integer.
>>    
>>
>
>Let me guess: You are looking for get_tid() :-)
>
>Bene
>.
>
>  
>

Re: Thread_Id

[Robert Hancock]

RVK wrote:
> Can anyone suggest me how to get the threadId using 2.6.x kernels. 
> pthread_self() does not work and returns some -ve integer.

What do you mean, negative integer? It's not an integer, it's a 
pthread_t, you're not even supposed to look at it..

-- 
Robert Hancock      Saskatoon, SK, Canada
To email, remove "nospam" from hancockr@nospamshaw.ca
Home Page: http://www.roberthancock.com/

Re: Thread_Id

[RVK]

Robert Hancock wrote:

> RVK wrote:
>
>> Can anyone suggest me how to get the threadId using 2.6.x kernels.
>> pthread_self() does not work and returns some -ve integer.
>
>
> What do you mean, negative integer? It's not an integer, it's a
> pthread_t, you're not even supposed to look at it..

What is pthread_t inturn defined to ? pthread_self for 2.4.x thread 
libraries return +ve number(as u have a objection me calling it as 
integer :-))

Raghu

>
> -- 
> Robert Hancock      Saskatoon, SK, Canada
> To email, remove "nospam" from hancockr@nospamshaw.ca
> Home Page: http://www.roberthancock.com/
>
> -
> 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: Thread_Id

[Arjan van de Ven]

On Thu, 2005-07-14 at 11:03 +0530, RVK wrote:
> Robert Hancock wrote:
> 
> > RVK wrote:
> >
> >> Can anyone suggest me how to get the threadId using 2.6.x kernels.
> >> pthread_self() does not work and returns some -ve integer.
> >
> >
> > What do you mean, negative integer? It's not an integer, it's a
> > pthread_t, you're not even supposed to look at it..
> 
> What is pthread_t inturn defined to ? pthread_self for 2.4.x thread 
> libraries return +ve number(as u have a objection me calling it as 
> integer :-))

it doesn't return a number it returns a pointer ;) or a floating point
number. You don't know :)

what it returns is a *cookie*. A cookie that you can only use to pass
back to various pthread functions.

Re: Thread_Id

[RVK]

Arjan van de Ven wrote:

>On Thu, 2005-07-14 at 11:03 +0530, RVK wrote:
>  
>
>>Robert Hancock wrote:
>>
>>    
>>
>>>RVK wrote:
>>>
>>>      
>>>
>>>>Can anyone suggest me how to get the threadId using 2.6.x kernels.
>>>>pthread_self() does not work and returns some -ve integer.
>>>>        
>>>>
>>>What do you mean, negative integer? It's not an integer, it's a
>>>pthread_t, you're not even supposed to look at it..
>>>      
>>>
>>What is pthread_t inturn defined to ? pthread_self for 2.4.x thread
>>libraries return +ve number(as u have a objection me calling it as
>>integer :-))
>>    
>>
>
>it doesn't return a number it returns a pointer ;) or a floating point
>number. You don't know :)
>
>what it returns is a *cookie*. A cookie that you can only use to pass
>back to various pthread functions.
>
>  
>
Hahaha......common. Please clarify following....
SYNOPSIS
       #include <pthread.h>

       pthread_t pthread_self(void);

DESCRIPTION
       pthread_self return the thread identifier for the calling thread.

bits/pthreadtypes.h:150:typedef unsigned long int pthread_t;

rvk

>-
>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: Thread_Id

[Arjan van de Ven]

On Thu, 2005-07-14 at 15:36 +0530, RVK wrote:

> >
> >it doesn't return a number it returns a pointer ;) or a floating point
> >number. You don't know :)
> >
> >what it returns is a *cookie*. A cookie that you can only use to pass
> >back to various pthread functions.
> >
> >  
> >
> Hahaha......common. Please clarify following....

I'm missing the joke

> SYNOPSIS
>        #include <pthread.h>
> 
>        pthread_t pthread_self(void);
> 
> DESCRIPTION
>        pthread_self return the thread identifier for the calling thread.

*identifier*.
It doesn't give a meaning beyond that, and if you look at other pthread
manpages (say pthread_join) it just wants that identifier back. If you
want to attach meaning to a thread identifier, please come up with a
manpage/standard that actually defines the meaning of it.

> 
> bits/pthreadtypes.h:150:typedef unsigned long int pthread_t;

and here you 
1) look at implementation details of your specific threading
implementation and 
2) you prove that your analysis is wrong since the implementation you
look at defines it as *unsigned* so it can't be negative. So what your
app does is clearly wrong even within the implementation you look at.


Other implementations are allowed to use different types for this. In
fact, I'd be surprised if NPTL and LinuxThreads would have the same
type... (they'll have the same size for ABI compat reasons of course,
but type... not so sure).

Re: Thread_Id

[RVK]

Arjan van de Ven wrote:

>On Thu, 2005-07-14 at 15:36 +0530, RVK wrote:
>
>  
>
>>>it doesn't return a number it returns a pointer ;) or a floating point
>>>number. You don't know :)
>>>
>>>what it returns is a *cookie*. A cookie that you can only use to pass
>>>back to various pthread functions.
>>>
>>>
>>>
>>>      
>>>
>>Hahaha......common. Please clarify following....
>>    
>>
>
>I'm missing the joke
>
>  
>
Its not a joke its a confusion created by the thread identifier.

>>SYNOPSIS
>>       #include <pthread.h>
>>
>>       pthread_t pthread_self(void);
>>
>>DESCRIPTION
>>       pthread_self return the thread identifier for the calling thread.
>>    
>>
>
>*identifier*.
>It doesn't give a meaning beyond that, and if you look at other pthread
>manpages (say pthread_join) it just wants that identifier back. If you
>want to attach meaning to a thread identifier, please come up with a
>manpage/standard that actually defines the meaning of it.
>
>  
>
>>bits/pthreadtypes.h:150:typedef unsigned long int pthread_t;
>>    
>>
>
>and here you
>1) look at implementation details of your specific threading
>implementation and
>2) you prove that your analysis is wrong since the implementation you
>look at defines it as *unsigned* so it can't be negative. So what your
>app does is clearly wrong even within the implementation you look at.
>
>
>  
>
So then what is the meaning of that typedef and why its still there ?

>Other implementations are allowed to use different types for this. In
>fact, I'd be surprised if NPTL and LinuxThreads would have the same
>type... (they'll have the same size for ABI compat reasons of course,
>but type... not so sure).
>
>  
>
I haven't faced the same returns with 2.4.18. So why is it so with 2.6.x 
kernels ? pthread_self() on 2.4.18 was returning the same as gettid() 
with 2.6.x.

rvk

>.
>
>  
>

Re: Thread_Id

[Arjan van de Ven]

> >
> So then what is the meaning of that typedef and why its still there ?

the typedef means that the *IMPLEMENTATION* uses an unsigned long to
store its cookie in.

> 
> >Other implementations are allowed to use different types for this. In
> >fact, I'd be surprised if NPTL and LinuxThreads would have the same
> >type... (they'll have the same size for ABI compat reasons of course,
> >but type... not so sure).
> >
> >  
> >
> I haven't faced the same returns with 2.4.18. So why is it so with 2.6.x 
> kernels ? pthread_self() on 2.4.18 was returning the same as gettid() 
> with 2.6.x.

pure luck. NPTL threading uses it to store a pointer to per thread info
structure; other threading (linuxthreads) may have stored a pid there to
identify the internal thread. nptl is 2.6 only so you might have
switched implementation of threading when you switched kernels.

Re: Thread_Id

[Jakub Jelinek]

On Thu, Jul 14, 2005 at 02:25:43PM +0200, Arjan van de Ven wrote:
> pure luck. NPTL threading uses it to store a pointer to per thread info
> structure; other threading (linuxthreads) may have stored a pid there to
> identify the internal thread. nptl is 2.6 only so you might have
> switched implementation of threading when you switched kernels.

Actually, in linuxthreads what pthread_self () returned has the first slot
in its internal threads array (up to max number of supported threads)
that was unused at thread creation time in the low order bits and sequence
number of thread creation in its high order bits.
So unless you are using yet another threading library (I thought NGPT
is dead for years...), the claim that you get the same numbers from
gettid() syscall under NPTL as pthread_self () gives you under LinuxThreads
is simply not true.  And you certainly shouldn't be using gettid ()
syscall in NPTL, as it is just an implementation detail that there is
a 1:1 mapping between NPTL threads and kernel threads.  It can change
at any time.

	Jakub

Re: Thread_Id

[Benedikt Spranger]

> And you certainly shouldn't be using gettid () syscall in NPTL, as it 
> is just an implementation detail that there is a 1:1 mapping between 
> NPTL threads and kernel threads.  It can change at any time.

Maybe I missed the point, but I thought the 1:1 mapping between NPTL
threads and kernel threads is one of the advantages of NPTL and the idea
of a userland scheduler is quite dead. 

So please let gettid do what man gettid assures:
gettid  returns the thread ID of the current process. This is equal to
the process ID (as returned by getpid(2)), unless the process is  part
of  a thread group (created by specifying the CLONE_THREAD flag to the
clone(2) system call). All processes in the same thread group have the
same PID, but each one has a unique TID.

Bene

Re: Thread_Id

[RVK]

Jakub Jelinek wrote:

>On Thu, Jul 14, 2005 at 02:25:43PM +0200, Arjan van de Ven wrote:
>  
>
>>pure luck. NPTL threading uses it to store a pointer to per thread info
>>structure; other threading (linuxthreads) may have stored a pid there to
>>identify the internal thread. nptl is 2.6 only so you might have
>>switched implementation of threading when you switched kernels.
>>    
>>
>
>Actually, in linuxthreads what pthread_self () returned has the first slot
>in its internal threads array (up to max number of supported threads)
>that was unused at thread creation time in the low order bits and sequence
>number of thread creation in its high order bits.
>So unless you are using yet another threading library (I thought NGPT
>is dead for years...), the claim that you get the same numbers from
>gettid() syscall under NPTL as pthread_self () gives you under LinuxThreads
>is simply not true.  And you certainly shouldn't be using gettid ()
>syscall in NPTL, as it is just an implementation detail that there is
>a 1:1 mapping between NPTL threads and kernel threads.  It can change
>at any time.
>
>  
>
Which ever is the implementation its expected to be backward compatible. 
Especially thread libraries. As lot of applications using that.

rvk

>	Jakub
>
>  
>

Re: Thread_Id

[Ian Campbell]

On Thu, 2005-07-14 at 15:36 +0530, RVK wrote:

> bits/pthreadtypes.h:150:typedef unsigned long int pthread_t;

That's an implementation detail which you cannot determine any
information from.

What Arjan is saying is that pthread_t is a cookie -- this means that
you cannot interpret it in any way, it is just a "thing" which you can
pass back to the API, that pthread_t happens to be typedef'd to unsigned
long int is irrelevant.  

Ian.

-- 
Ian Campbell
Current Noise: Nile - Annihilation Of The Wicked

Don't tell me what you dreamed last night for I've been reading Freud.

Re: Thread_Id

[RVK]

Ian Campbell wrote:

>On Thu, 2005-07-14 at 15:36 +0530, RVK wrote:
>
>  
>
>>bits/pthreadtypes.h:150:typedef unsigned long int pthread_t;
>>    
>>
>
>That's an implementation detail which you cannot determine any
>information from.
>
>What Arjan is saying is that pthread_t is a cookie -- this means that
>you cannot interpret it in any way, it is just a "thing" which you can
>pass back to the API, that pthread_t happens to be typedef'd to unsigned
>long int is irrelevant.
>
>  
>
Do you want to say for both 2.6.x and 2.4.x I should interpret that way ?

rvk

>Ian.
>
>--
>Ian Campbell
>Current Noise: Nile - Annihilation Of The Wicked
>
>Don't tell me what you dreamed last night for I've been reading Freud.
>.
>
>  
>

Re: Thread_Id

[Ian Campbell]

On Thu, 2005-07-14 at 16:32 +0530, RVK wrote:
> Ian Campbell wrote:
> >What Arjan is saying is that pthread_t is a cookie -- this means that
> >you cannot interpret it in any way, it is just a "thing" which you can
> >pass back to the API, that pthread_t happens to be typedef'd to unsigned
> >long int is irrelevant.
> Do you want to say for both 2.6.x and 2.4.x I should interpret that way ?

As I understand it, yes, you should never try and assign any meaning to
the values. The fact that you may have been able to find some apparent
meaning under 2.4 is just a coincidence.

Ian.

-- 
Ian Campbell
Current Noise: Nile - Annihilation Of The Wicked

BOFH excuse #127:

Sticky bits on disk.

Re: Thread_Id

[RVK]

Ian Campbell wrote:

>On Thu, 2005-07-14 at 16:32 +0530, RVK wrote:
>  
>
>>Ian Campbell wrote:
>>    
>>
>>>What Arjan is saying is that pthread_t is a cookie -- this means that
>>>you cannot interpret it in any way, it is just a "thing" which you can
>>>pass back to the API, that pthread_t happens to be typedef'd to unsigned
>>>long int is irrelevant.
>>>      
>>>
>>Do you want to say for both 2.6.x and 2.4.x I should interpret that way ?
>>    
>>
>
>As I understand it, yes, you should never try and assign any meaning to
>the values. The fact that you may have been able to find some apparent
>meaning under 2.4 is just a coincidence.
>
>  
>
Iam sorry I don't agree on this. This confusion have created only becoz 
of the different behavior of pthread_self() on 2.4.18 and 2.6.x kernels. 
And Iam looking for clarifying my doubt. I can't digest this at all.

rvk

>Ian.
>
>--
>Ian Campbell
>Current Noise: Nile - Annihilation Of The Wicked
>
>BOFH excuse #127:
>
>Sticky bits on disk.
>.
>
>  
>

Re: Thread_Id

[J.A. Magallon]

On 07.14, RVK wrote:
> Ian Campbell wrote:
> 
> >On Thu, 2005-07-14 at 16:32 +0530, RVK wrote:
> >  
> >
> >>Ian Campbell wrote:
> >>    
> >>
> >>>What Arjan is saying is that pthread_t is a cookie -- this means that
> >>>you cannot interpret it in any way, it is just a "thing" which you can
> >>>pass back to the API, that pthread_t happens to be typedef'd to unsigned
> >>>long int is irrelevant.
> >>>      
> >>>
> >>Do you want to say for both 2.6.x and 2.4.x I should interpret that way ?
> >>    
> >>
> >
> >As I understand it, yes, you should never try and assign any meaning to
> >the values. The fact that you may have been able to find some apparent
> >meaning under 2.4 is just a coincidence.
> >
> >  
> >
> Iam sorry I don't agree on this. This confusion have created only becoz 
> of the different behavior of pthread_self() on 2.4.18 and 2.6.x kernels. 
> And Iam looking for clarifying my doubt. I can't digest this at all.
> 

It is simple: none ever never told you that a pthread_t has nothing to do
with a pid. pthreads is a standard and portable implementation that
guarantees you can port _pthread_ code between posix systems. It uses
an internal opaque type to identify threads, but you should never relay on
it have nothing to do with pids. The fact that somewhere-in-time-in-some-os
the pthread_t equals the pid/tid/ etc is just pure chance. If you had
code relaying on this, it is just broken. Where is stated if pthread_t is
the tid, an index into a table internal to pthread library, a pointer
to an struct (mmm, bloken on 64 bits?) or what ?

Whatif:
- you swith kernels and thread library implementation ?
- you go solaris (it has user level threads ?)

I think one of the sources of the confussion is that:
- man pages about system calls talk about 'threads', but that should be
  read as 'sibling _processes_ created via clone(CLONE_THREAD) syscall'.
- man pages about phthreads library also talk about 'threads', but that
  should be read as 'posix threads created via pthread_create'.
And none guarantees that both 'threads' are the same.

If you just want to use gettid(), don't go further that clone().
If you use pthread_create(), forget about gettid().

(AFAIK ;) )

--
J.A. Magallon <jamagallon()able!es>     \               Software is like sex:
werewolf!able!es                         \         It's better when it's free
Mandriva Linux release 2006.0 (Cooker) for i586
Linux 2.6.12-jam9 (gcc 4.0.1 (4.0.1-0.2mdk for Mandriva Linux release 2006.0))

Re: Thread_Id

[RVK]

J.A. Magallon wrote:

>On 07.14, RVK wrote:
>  
>
>>Ian Campbell wrote:
>>
>>    
>>
>>>On Thu, 2005-07-14 at 16:32 +0530, RVK wrote:
>>>
>>>
>>>      
>>>
>>>>Ian Campbell wrote:
>>>>
>>>>
>>>>        
>>>>
>>>>>What Arjan is saying is that pthread_t is a cookie -- this means that
>>>>>you cannot interpret it in any way, it is just a "thing" which you can
>>>>>pass back to the API, that pthread_t happens to be typedef'd to unsigned
>>>>>long int is irrelevant.
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>Do you want to say for both 2.6.x and 2.4.x I should interpret that way ?
>>>>
>>>>
>>>>        
>>>>
>>>As I understand it, yes, you should never try and assign any meaning to
>>>the values. The fact that you may have been able to find some apparent
>>>meaning under 2.4 is just a coincidence.
>>>
>>>
>>>
>>>      
>>>
>>Iam sorry I don't agree on this. This confusion have created only becoz
>>of the different behavior of pthread_self() on 2.4.18 and 2.6.x kernels.
>>And Iam looking for clarifying my doubt. I can't digest this at all.
>>
>>    
>>
>
>It is simple: none ever never told you that a pthread_t has nothing to do
>with a pid. pthreads is a standard and portable implementation that
>guarantees you can port _pthread_ code between posix systems. It uses
>an internal opaque type to identify threads, but you should never relay on
>it have nothing to do with pids. The fact that somewhere-in-time-in-some-os
>the pthread_t equals the pid/tid/ etc is just pure chance. If you had
>code relaying on this, it is just broken. Where is stated if pthread_t is
>the tid, an index into a table internal to pthread library, a pointer
>to an struct (mmm, bloken on 64 bits?) or what ?
>
>  
>
Understood on pid/tid and thread identifier diffrentiation. The question 
now is why pthread_t is typedef as unsigned long ?

>Whatif:
>- you swith kernels and thread library implementation ?
>- you go solaris (it has user level threads ?)
>
>I think one of the sources of the confussion is that:
>- man pages about system calls talk about 'threads', but that should be
>  read as 'sibling _processes_ created via clone(CLONE_THREAD) syscall'.
>- man pages about phthreads library also talk about 'threads', but that
>  should be read as 'posix threads created via pthread_create'.
>And none guarantees that both 'threads' are the same.
>
>  
>
Yes its very important to have clarity in the manuals on this.

>If you just want to use gettid(), don't go further that clone().
>If you use pthread_create(), forget about gettid().
>
>  
>
Does the man pages for pthread_create or clone or gettid states this ?

rvk

>(AFAIK ;) )
>
>--
>J.A. Magallon <jamagallon()able!es>     \               Software is like sex:
>werewolf!able!es                         \         It's better when it's free
>Mandriva Linux release 2006.0 (Cooker) for i586
>Linux 2.6.12-jam9 (gcc 4.0.1 (4.0.1-0.2mdk for Mandriva Linux release 2006.0))
>
>
>.
>
>  
>

Re: Thread_Id

[Ian Campbell]

[-- Attachment #1: Type: text/plain, Size: 345 bytes --]

On Fri, 2005-07-15 at 11:39 +0530, RVK wrote:
> Understood on pid/tid and thread identifier diffrentiation. The question 
> now is why pthread_t is typedef as unsigned long ?

It's just an arbitrary type that is big enough to contain the cookie.

Ian.
-- 
Ian Campbell

It is better to give than to lend, and it costs about the same.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Thread_Id

[Robert Hancock]

RVK wrote:
> Ian Campbell wrote:
> 
>> On Thu, 2005-07-14 at 15:36 +0530, RVK wrote:
>>
>>  
>>
>>> bits/pthreadtypes.h:150:typedef unsigned long int pthread_t;
>>>   
>>
>>
>> That's an implementation detail which you cannot determine any
>> information from.
>>
>> What Arjan is saying is that pthread_t is a cookie -- this means that
>> you cannot interpret it in any way, it is just a "thing" which you can
>> pass back to the API, that pthread_t happens to be typedef'd to unsigned
>> long int is irrelevant.
>>
>>  
>>
> Do you want to say for both 2.6.x and 2.4.x I should interpret that way ?
> 
> rvk

Indeed, for ANY OS using pthreads it should be interpreted that way..