Hi guys,

I know it has been discussed on the forum before but it's still very unclear for me...

I read on one of the thread on LQ that processes in brackets [] are kernel threads...or processes that were started by init process...
first of all, are all the processes that were started by init process, kernel threads/processes? I'm abit confused about this one.

Also, why some of the processes that are not listed under "kthread" in the output of "ps -ejH", bracketed in the output of "ps aux"? Do they show different things or how does it work?

Thanks

Have you tried looking at the description of the individual flags
in the ps man-page?

why do people do that all the time? Maybe I didn't understand or missed something in the man page...I have already mentioned that I'm confused about some stuff...

This is a forum where people ask for HELP...It's not like I've committed a crime....if you have the knowledge and the time, just respond to the question...why are you interrogating? If you do know just answer, if not BROWSE AWAY...

can someone help me with this?

Well ... the best way of helping people is to enable them to help
themselves. Reading the man-page is always the best starting point.


If that's not your idea of help, just ignore my responses. And if
your idea of "getting help" is "being spoon-fed" - who knows, maybe I'll
just ignore your questions in the future...

Might try http://linux.about.com/od/commands/l/blcmdl1_ps.htm

Much clearer than the normal Man Page.

It points out that PS options/flags relate to Unix, BSD and GNU
Unix requires a leading hyphen
BSD omits the hyphen
GNU requires two hyphens
Just guessing that use of alternative options cause the differences in the bracketing that you have noted

Thanks but I've already tried that and it still shows the same thing. Like, say, nfsd in output of "aux" is bracketed, but in output of "ejH" is not listed under kthread:
funny thing is, nfsd4 is under kthread and is also bracketed...I don't get it.

Is this what you are looking for?

Kernel Threads
Kernel threads consist of a set of registers, a stack, and a few corresponding kernel data structures. When kernel threads are used, the operating system will have a descriptor for each thread belonging to a process and it will schedule all the threads. Unlike processes, all threads within a process share the same address space. Similar to processes, when a kernel thread makes a blocking call, only that thread blocks. All modern machines support kernel threads, most often via the POSIX threads interface ``pthreads''. Some dedicated parallel machines support kernel threads poorly or not at all. For example, the Blue Gene/L microkernel does not support pthreads.

The purported advantage of kernel threads over processes is faster creation and context switching compared with processes. For shared-memory multiprocessor architectures, the kernel is able to dispatch threads of one process on several processors, which leads to automatic load balancing within the nodes. For parallel programming, threads allow different parts of the parallel program to communicate by directly accessing each others' memory, which allows very efficient, fine-grained communication.

Kernel threads share a single copy of the entire address space, including regions such as global data that may cause conflicts if used by multiple threads simultaneously. Threads can also cause unintentional data sharing, which leads to corruption and race conditions. To avoid this unintentional sharing, programs must often be modified to either lock or access separate copies of common data structures. Several very widely used language features are unsafe when used with threads, such as the use of global and static variables, or the idiom of returning a reference to a static buffer. Especially with large existing codebases with many global variables, this makes kernel threads very difficult to use because in most implementations of kernel threads, it is not possible to assign each thread a private set of global variables.

Kernel threads are considered ``lightweight,'' and one would expect the number of threads to only be limited by address space and processor time. Since every thread needs only a stack and a small data structure describing the thread, in principle this limit should not be a problem. But in practice, we found that many platforms impose hard limits on the maximum number of pthreads that can be created in a process. Table 2 in Section 4 shows the practical limitations on pthreads on several stock systems.

In particular, operating system kernels tend to see kernel threads as a special kind of process rather than a unique entity. For example, in the Solaris kernel threads are called ``light weight processes'' (LWP's). Linux actually creates kernel threads using a special variation of fork called ``clone,'' and until recently gave each thread a separate process ID. Because of this heritage, in practice kernel threads tend to be closer in memory and time cost to processes than user-level threads, although recent work has made some progress in closing the gap, including K42 [5] and the Native POSIX Threading Library (NPTL) and Linux O(1) scheduler.

I have seen this mentioned too - I suspect it is mis-interpretation of the data. And now it's been repeated so often as to become "fact".
I haven't looked at the code, so I can't say for sure.
Here is a quote from the "man ps" on one of my Arch systems that appears relevantTry your commands with the "c" option and you'll see the difference.

There is a flag in /proc/<pid>/stat that indicates whether that process is a kernel thread, so I'd be inclined to believe the option that supports process hierarchy (-H).

awesome! Thanks...

This is correct, try execl(program_path, NULL) and you will see your process listed in brackets.

Uh, what is actually the correct explaination here? I mean, i have read in books that the processes in brackets are kernel threads, but other books says that processes in brackets have the brackets because they are processes which has been swapped out because they are not in active use by the system at that time... so does anyone know for sure what the answer to this actually is? both statements are coming from people with a high knowledge of linux and networking and they have like 19-20 years experience .. i also thought they were kernel threads, but now when a person with 19 years experience which has also written the books on sendmail, qmail, postfix and a dozen other books says that its because the processes are swapped out because they are inactive im getting a little unsure about this...

what do you guys say?

bumping the thread, noone knows this for sure? ..i know there are many very skilled people here

Might have been true at one time, but now Linux doesn't swap tasks out. That function disappeared years ago - before I even started using Linux.
Pity Linus didn't rename the swap partition/file at the same time.

Ok, the book were they say that processes in square brackets are processes swapped out is from 2008, but i guess they`re wrong then..

Don't believe everything you read. Including here.
I found the changelog for that function disappearing once - if I get bored I might go looking again.