On Fri, Jun 23, 2006 at 04:42:11PM -0400, Valdis.Kletnieks (at) vt (dot) edu [email concealed] wrote:
> On Fri, 23 Jun 2006 15:16:08 EDT, "Frank S Posluszny, III" said:
>
> > > There are also some processes absent from process_to_com entirely,
> > > like processes 7 and 12:
> >
> > Sorry, don't know about that one.
>
> Number *that* low on a Linuxoid kernel is almost certainly a kernel
> thread (see kernel/pid.c and the use of RESERVED_PIDS in alloc_pidmap()
> for all the gory details, but basically, all PIDs under 300 (by default)
> are reserved for kernel threads). It's quite possible that 7 and 12
> were threads created during boot to do things like scsi initialization
> and so on (on my laptop, PID 8 is kblockd, and 9 is kacpid, then a
> big jump to 117 cqueue and 120 khubd (USB support)).
>
> If you're *really* curious to identify it, you'd have to add instrumentation to
> kthread_create() in kernel/kthread.c and/or the kernel_thread() function in
> arch/<mumble>/kernel/process.c - kernel_thread() calls do_fork() which is
> what will end up assigning the PID to the thread.... You probably don't
> want to instrument do_fork() itself unless you plan to spam yourself with
> printk output for *every* fork() you do.. ;)

I was under the impression that process_id as it appears in the
database is strictly internal to the database, not the pid of the
process on the host:

mysql> select pid, process_id from process;
+------+------------+
| pid | process_id |
+------+------------+
| 5952 | 1 |
| 5788 | 2 |
| 0 | 3 |
| 5953 | 4 |
| 5954 | 5 |
| 5709 | 6 |
| 1 | 7 |
| 5562 | 8 |
| 5866 | 9 |

and process_to_com refers to this database process_id, not the
kernel's process id... or?

-troy

[ reply ]