Re: kthreads->kproc and back to kthread.. next patch

Ivan Voras wrote:
> Julian Elischer wrote:
>> Here is the link to the next patch.
>>
>> this introduces (back) the kthread_create (etc) calls but now they
>> make threads..
> 
>> it may also be worth adding some help for people to make a new kproc,
>> and populate it with a number of kthreads.
> 
> For example, why would we do that? :)
> 
> A practical example: GEOM modules often spawn separate execution 
> contexts to handle non-trivial IO requests. These threads are usually 
> created at most once per GEOM device and live until that device goes 
> away. GEOM framework itself has several execution contexts (g_up, 
> g_down, g_event) which call "methods" from GEOM classes. Should we spawn 
> one "dummy" kproc per GEOM class and then kthreads in it for devices? If 
> "raw" kthreads can be spawned, to which kproc will they belong (if any)? 
>  Is the difference between kthread and kproc here purely aesthetic?
> 
> In other words: when should one create a kproc and when a kthread?

If you wanted to limit CPU usage for a particular group of threads it 
may be worth grouping them into a process and then you could have 
some control over them with 'nice'.

Another case,

The AIO threads need to be processes because each of them needs 
a different address space that can be hacked to cover the address space of the 
process they are working for.

The Idle threads couldbe in their own process so you can easily see how much cpu idle..

here's what that looks like in top -SH

last pid: 34941;  load averages:  1.02,  1.01,  1.00  up 0+18:26:04  16:30:40
80 processes:  5 running, 57 sleeping, 18 waiting
CPU states:  0.0% user,  0.0% nice,  0.0% system,  0.0% interrupt,  100% idle
Mem: 27M Active, 462M Inact, 160M Wired, 404K Cache, 112M Buf, 2358M Free
Swap: 6144M Total, 6144M Free

  PID USERNAME PRI NICE   SIZE    RES STATE  C   TIME   WCPU COMMAND
    2 root     171 i-64     0K    32K CPU3   3 742:14 99.02% idle: cpu3
    2 root     171 i-64     0K    32K RUN    2 742:14 99.02% idle: cpu2
    2 root     171 i-64     0K    32K RUN    0 742:14 98.73% idle: cpu1
    2 root     171 i-64     0K    32K RUN    1 742:14 98.44% idle: cpi0
   40 root      20    -     0K     8K syncer 1   1:07  0.49% syncer
   10 root     -32    -     0K     8K WAIT   0   3:10  0.20% swi4: clock sio
    0 root      96    0     0K    32K WAIT   2 742:14  0.00% swapper

or top -S

  PID USERNAME  THR PRI NICE   SIZE    RES STATE  C   TIME   WCPU COMMAND
    0 root        4 171 i-64     0K    32K CPU0   0 743:43 395.80% idle
   40 root        1  20    -     0K     8K syncer 1   1:07  0.10% syncer
   10 root        1 -32    -     0K     8K WAIT   0   3:10  0.00% swi4: clock sio
    0 root        1 171 i-64     0K    32K CPU0   0 743:43 395.80% swapper

There are many other reasons you may want to group kernel threads.
for example a single process with all teh interrupt threads in it might
be useful for accounting for interupts in some ways.



> 
> _______________________________________________
> freebsd-current_at_freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"