Date: Mon, 22 Oct 2007 16:40:08 -0700 From: Julian Elischer <julian@elischer.org> To: Ivan Voras <ivoras@freebsd.org> Cc: freebsd-current@freebsd.org Subject: Re: kthreads->kproc and back to kthread.. next patch Message-ID: <471D34D8.8020009@elischer.org> In-Reply-To: <ffijts$tqt$1@ger.gmane.org> References: <471BDA2E.9040801@elischer.org> <ffijts$tqt$1@ger.gmane.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?471D34D8.8020009>