/bin/ps output
Man, this looks ugly. I'm just waiting for Bill Irwin, or Anton to trump me, though.
PID TTY STAT TIME COMMAND
1 ? S 0:10 init
2 ? SW 0:00 [migration/0]
3 ? SWN 0:00 [ksoftirqd/0]
4 ? SW 0:00 [migration/1]
5 ? SWN 0:00 [ksoftirqd/1]
6 ? SW 0:00 [migration/2]
7 ? RWN 0:00 [ksoftirqd/2]
8 ? SW 0:00 [migration/3]
9 ? SWN 0:00 [ksoftirqd/3]
10 ? SW 0:00 [migration/4]
11 ? SWN 0:00 [ksoftirqd/4]
12 ? SW 0:00 [migration/5]
13 ? SWN 0:00 [ksoftirqd/5]
14 ? SW 0:00 [migration/6]
15 ? RWN 0:00 [ksoftirqd/6]
16 ? SW 0:00 [migration/7]
17 ? SWN 0:00 [ksoftirqd/7]
18 ? SW 0:00 [events/0]
19 ? SW 0:00 [events/1]
20 ? SW 0:00 [events/2]
21 ? SW 0:00 [events/3]
22 ? SW 0:00 [events/4]
23 ? SW 0:00 [events/5]
24 ? SW 0:00 [events/6]
25 ? SW 0:00 [events/7]
26 ? SW 0:00 [kswapd0]
28 ? SW 0:00 [pdflush]
27 ? SW 0:00 [pdflush]
29 ? SW 0:00 [aio/0]
30 ? SW 0:00 [aio/1]
31 ? SW 0:00 [aio/2]
32 ? SW 0:00 [aio/3]
33 ? SW 0:00 [aio/4]
34 ? SW 0:00 [aio/5]
35 ? SW 0:00 [aio/6]
36 ? SW 0:00 [aio/7]
37 ? SW 0:00 [scsi_eh_0]
38 ? SW 0:00 [scsi_eh_1]
39 ? SW 0:00 [scsi_eh_2]
40 ? SW 0:00 [kseriod]
41 ? DW 0:00 [kjournald]
115 ? SW 0:00 [kjournald]
116 ? DW 0:00 [kjournald]
117 ? SW 0:00 [kjournald]Signature · 2 lines
Dave Hansen [email protected]
From: Dave Hansen <[email protected]>
Date: Fri, 11 Oct 2002 20:36:22 -0700
Man, this looks ugly. I'm just waiting for Bill Irwin, or Anton to trump me, though.
We could make them threads of process 0 :-)
On Fri, 11 Oct 2002, David S. Miller wrote:
[ 8 gazillion kernel threads ]
Quoted 1 line
We could make them threads of process 0 :-)
That was my first thought too, but on second thought I think we've got an excessive amount of kernel threads and should do something about that...
regards,
Rik
Signature · 3 lines
Bravely reimplemented by the knights who say "NIH". http://www.surriel.com/ http://distro.conectiva.com/ Current spamtrap: <a href=mailto:"[email protected]">[email protected]</a>
Quoted 9 lines · Rik van Riel
On Fri, 11 Oct 2002, David S. Miller wrote:
[ 8 gazillion kernel threads ]
Quoted 1 line
We could make them threads of process 0 :-)
That was my first thought too, but on second thought I think we've got an excessive amount of kernel threads and should do something about that...
Migration workqueues ?
Quoted 2 lines · Dave Hansen
Man, this looks ugly. I'm just waiting for Bill Irwin, or Anton to trump me, though.
UID PID PPID C STIME TTY TIME CMD root 1 0 0 Oct09 ? 00:00:08 init root 2 1 0 Oct09 ? 00:00:00 [migration_CPU0] root 3 1 0 Oct09 ? 00:00:00 [ksoftirqd_CPU0] root 4 1 0 Oct09 ? 00:00:00 [migration_CPU1] root 5 1 0 Oct09 ? 00:00:00 [ksoftirqd_CPU1] root 6 1 0 Oct09 ? 00:00:00 [migration_CPU2] root 7 1 0 Oct09 ? 00:00:00 [ksoftirqd_CPU2] root 8 1 0 Oct09 ? 00:00:00 [migration_CPU3] root 9 1 0 Oct09 ? 00:00:00 [ksoftirqd_CPU3] root 10 1 0 Oct09 ? 00:00:00 [migration_CPU4] root 11 1 0 Oct09 ? 00:00:00 [ksoftirqd_CPU4] root 12 1 0 Oct09 ? 00:00:00 [migration_CPU5] root 13 1 0 Oct09 ? 00:00:00 [ksoftirqd_CPU5] root 14 1 0 Oct09 ? 00:00:00 [migration_CPU6] root 15 1 0 Oct09 ? 00:00:00 [ksoftirqd_CPU6] root 16 1 0 Oct09 ? 00:00:00 [migration_CPU7] root 17 1 0 Oct09 ? 00:00:00 [ksoftirqd_CPU7] root 18 1 0 Oct09 ? 00:00:00 [migration_CPU8] root 19 1 0 Oct09 ? 00:00:00 [ksoftirqd_CPU8] root 20 1 0 Oct09 ? 00:00:00 [migration_CPU9] root 21 1 0 Oct09 ? 00:00:00 [ksoftirqd_CPU9] root 22 1 0 Oct09 ? 00:00:00 [migration_CPU10] root 23 1 0 Oct09 ? 00:00:00 [ksoftirqd_CPU10] root 24 1 0 Oct09 ? 00:00:00 [migration_CPU11] root 25 1 0 Oct09 ? 00:00:00 [ksoftirqd_CPU11] root 26 1 0 Oct09 ? 00:00:00 [migration_CPU12] root 27 1 0 Oct09 ? 00:00:00 [ksoftirqd_CPU12] root 28 1 0 Oct09 ? 00:00:00 [migration_CPU13] root 29 1 0 Oct09 ? 00:00:00 [ksoftirqd_CPU13] root 30 1 0 Oct09 ? 00:00:00 [migration_CPU14] root 31 1 0 Oct09 ? 00:00:00 [ksoftirqd_CPU14] root 32 1 0 Oct09 ? 00:00:00 [migration_CPU15] root 33 1 0 Oct09 ? 00:00:00 [ksoftirqd_CPU15] root 34 1 0 Oct09 ? 00:00:00 [events/0] root 35 1 0 Oct09 ? 00:00:00 [events/1] root 36 1 0 Oct09 ? 00:00:00 [events/2] root 37 1 0 Oct09 ? 00:00:00 [events/3] root 38 1 0 Oct09 ? 00:00:00 [events/4] root 39 1 0 Oct09 ? 00:00:00 [events/5] root 40 1 0 Oct09 ? 00:00:00 [events/6] root 41 1 0 Oct09 ? 00:00:00 [events/7] root 42 1 0 Oct09 ? 00:00:00 [events/8] root 43 1 0 Oct09 ? 00:00:00 [events/9] root 44 1 0 Oct09 ? 00:00:00 [events/10] root 45 1 0 Oct09 ? 00:00:00 [events/11] root 46 1 0 Oct09 ? 00:00:00 [events/12] root 47 1 0 Oct09 ? 00:00:00 [events/13] root 48 1 0 Oct09 ? 00:00:00 [events/14] root 49 1 0 Oct09 ? 00:00:00 [events/15] root 71 1 0 Oct09 ? 00:00:00 [pdflush] root 70 1 0 Oct09 ? 00:02:24 [pdflush] root 69 1 0 Oct09 ? 00:00:00 [kswapd0] root 68 1 0 Oct09 ? 00:00:00 [kswapd1] root 67 1 0 Oct09 ? 00:00:00 [kswapd2] root 66 1 0 Oct09 ? 00:00:00 [kswapd3] root 72 1 0 Oct09 ? 00:00:00 [aio/0] root 73 1 0 Oct09 ? 00:00:00 [aio/1] root 74 1 0 Oct09 ? 00:00:00 [aio/2] root 75 1 0 Oct09 ? 00:00:00 [aio/3] root 76 1 0 Oct09 ? 00:00:00 [aio/4] root 77 1 0 Oct09 ? 00:00:00 [aio/5] root 78 1 0 Oct09 ? 00:00:00 [aio/6] root 79 1 0 Oct09 ? 00:00:00 [aio/7] root 80 1 0 Oct09 ? 00:00:00 [aio/8] root 81 1 0 Oct09 ? 00:00:00 [aio/9] root 82 1 0 Oct09 ? 00:00:00 [aio/10] root 83 1 0 Oct09 ? 00:00:00 [aio/11] root 84 1 0 Oct09 ? 00:00:00 [aio/12] root 85 1 0 Oct09 ? 00:00:00 [aio/13] root 86 1 0 Oct09 ? 00:00:00 [aio/14] root 87 1 0 Oct09 ? 00:00:00 [aio/15] root 88 1 0 Oct09 ? 00:00:00 [scsi_eh_0] root 264 1 0 Oct09 ? 00:00:00 /sbin/syslogd root 267 1 0 Oct09 ? 00:00:01 /sbin/klogd root 274 1 0 Oct09 ? 00:00:00 /usr/sbin/inetd root 279 1 0 Oct09 ? 00:00:00 /usr/sbin/netserver root 285 1 0 Oct09 ? 00:00:00 /usr/sbin/sshd root 288 1 0 Oct09 ? 00:00:07 /usr/sbin/ntpd root 291 1 0 Oct09 tty1 00:00:00 /sbin/getty 38400 tty1 root 292 1 0 Oct09 tty2 00:00:00 /sbin/getty 38400 tty2 root 293 1 0 Oct09 tty3 00:00:00 /sbin/getty 38400 tty3 root 294 1 0 Oct09 tty4 00:00:00 /sbin/getty 38400 tty4 root 295 1 0 Oct09 tty5 00:00:00 /sbin/getty 38400 tty5 root 296 1 0 Oct09 tty6 00:00:00 /sbin/getty 38400 tty6 root 297 1 0 Oct09 ttyS0 00:00:00 -bash root 303 1 0 Oct09 ? 00:00:00 sshd -p 1976 root 9582 285 0 Oct10 ? 00:00:00 /usr/sbin/sshd wli 9584 9582 0 Oct10 ? 00:00:01 /usr/sbin/sshd wli 9585 9584 0 Oct10 pts/0 00:00:00 -zsh root 9589 285 0 Oct10 ? 00:00:00 /usr/sbin/sshd wli 9591 9589 0 Oct10 ? 00:00:00 /usr/sbin/sshd wli 9592 9591 0 Oct10 pts/1 00:00:00 -zsh root 5901 285 0 20:44 ? 00:00:00 /usr/sbin/sshd wli 5903 5901 0 20:44 ? 00:00:00 /usr/sbin/sshd wli 5904 5903 1 20:44 pts/2 00:00:00 -zsh wli 5907 5904 0 20:44 pts/2 00:00:00 ps -fade wli 5908 5904 0 20:44 pts/2 00:00:00 less
Quoted 3 lines
Man, this looks ugly. I'm just waiting for Bill Irwin, or Anton to trump me, though.
Id like to oblige but I hear the list has a 100kB limit :)
Anton
Quoted 2 lines · Anton Blanchard
Id like to oblige but I hear the list has a 100kB limit :) Anton
Bah! I'm at a competitive disadvantage because I've got a lesser BITS_PER_LONG. No matter, NR_CPUS > BITS_PER_LONG shall be conquered and the explosion of kernel threads will be quite visible (though unfortunately probably post-freeze).
Cheers,
Bill
Quoted 5 lines
Bah! I'm at a competitive disadvantage because I've got a lesser
BITS_PER_LONG. No matter,NR_CPUS>BITS_PER_LONGshall be conquered and the explosion of kernel threads will be quite visible (though unfortunately probably post-freeze).
Speaking of which, the recent CONFIG_NR_CPUS addition shows just how bloated all our [NR_CPU] structures are. We need to get serious about using the per cpu data stuff. Going from 32 to 64 was over 500kB on my ppc64 build.
Anton
From: Anton Blanchard <[email protected]>
Date: Sat, 12 Oct 2002 14:09:59 +1000
Speaking of which, the recent CONFIG_NR_CPUS addition shows just how bloated all our [NR_CPU] structures are. We need to get serious about using the per cpu data stuff. Going from 32 to 64 was over 500kB on my ppc64 build.
In fact, thinking about this some more, we should make the ".per_cpu" bits emit a table entry instead of some dummy object which takes up space. The table entry would be in the special .per_cpu section still but be just a size value.
We should do this on both SMP and non-SMP and it will shrink the kernel image size in both cases.
I don't have the time to implement this so I'll shut up now :-)
Quoted 4 lines · David S. Miller
In fact, thinking about this some more, we should make the ".per_cpu" bits emit a table entry instead of some dummy object which takes up space. The table entry would be in the special .per_cpu section still but be just a size value.
That's more complicated. Using the linker to help out with layout is definitely helpful. If you want to omit the per-cpu area from the kernel image, then arrange for it to be .bss.
r~
From: Richard Henderson <[email protected]>
Date: Sat, 12 Oct 2002 13:15:01 -0700
Quoted 4 lines · David S. Miller
In fact, thinking about this some more, we should make the ".per_cpu" bits emit a table entry instead of some dummy object which takes up space. The table entry would be in the special .per_cpu section still but be just a size value.
That's more complicated.
Hmm, we put arbitrary tables of information into seperate elf sections already. Consider the exception fixup mechanism for example. That's the kind of thing I was thinking about.
Oh I see, you're saying that then getting at the things symbolically will be painful. Yes it needs more thought.
If you want to omit the per-cpu area from the kernel image, then arrange for it to be .bss.
Good idea, well on SMP it can be marked throw-away (ie. __init_data).
Quoted 2 lines
Good idea, well on SMP it can be marked throw-away (ie.
__init_data).
We could also only create per cpu data areas when cpu_possible() is true, instead of NR_CPUS worth. That might be a little dangerous however.
Anton
Quoted 1 line · David S. Miller
Good idea, well on SMP it can be marked throw-away (ie.
__init_data).
Or you could use it for cpu0.
r~
Quoted 11 lines · Anton Blanchard
Quoted 5 lines
Bah! I'm at a competitive disadvantage because I've got a lesser
BITS_PER_LONG. No matter,NR_CPUS>BITS_PER_LONGshall be conquered and the explosion of kernel threads will be quite visible (though unfortunately probably post-freeze).Speaking of which, the recent
CONFIG_NR_CPUSaddition shows just how bloated all our [NR_CPU] structures are. We need to get serious about using the per cpu data stuff. Going from 32 to 64 was over 500kB on my ppc64 build.
Half of which is in timer.c.
mnm:/usr/src/25> size kernel/timer.o
text data bss dec hex filename
4960 100 167648 172708 2a2a4 kernel/timer.o
That's with NR_CPUS=32. Show me yours.
Using the percpu stuff will not significantly reduce this. Some new data structure might be needed.
Quoted 8 lines
Half of which is in
timer.c.mnm:/usr/src/25> size
kernel/timer.o
text data bss dec hex filename
4960 100 167648 172708 2a2a4kernel/timer.oThat's with NR_CPUS=32. Show me yours.
Its not like me to miss show and tell.
CONFIG_NR_CPUS=32:
text data bss dec hex filename
8488 267544 71392 347424 54d20 kernel/timer.o
CONFIG_NR_CPUS=64:
text data bss dec hex filename
8488 533784 137568 679840 a5fa0 kernel/timer.o
Ouch.
Anton
Quoted 2 lines · Dave Hansen
Man, this looks ugly. I'm just waiting for Bill Irwin, or Anton to trump me, though.
If I may rehash, since it is O(cpus), hence 1MB of ZONE_NORMAL stacks...
UID PID PPID C STIME TTY TIME CMD root 1 0 4 18:56 ? 00:00:09 init root 2 1 0 18:56 ? 00:00:00 [migration/0] root 3 1 0 18:56 ? 00:00:00 [ksoftirqd/0] root 4 1 0 18:56 ? 00:00:00 [migration/1] root 5 1 0 18:56 ? 00:00:00 [ksoftirqd/1] root 6 1 0 18:56 ? 00:00:00 [migration/2] root 7 1 0 18:56 ? 00:00:00 [ksoftirqd/2] root 8 1 0 18:56 ? 00:00:00 [migration/3] root 9 1 0 18:56 ? 00:00:00 [ksoftirqd/3] root 10 1 0 18:56 ? 00:00:00 [migration/4] root 11 1 0 18:56 ? 00:00:00 [ksoftirqd/4] root 12 1 0 18:56 ? 00:00:00 [migration/5] root 13 1 0 18:56 ? 00:00:00 [ksoftirqd/5] root 14 1 0 18:56 ? 00:00:00 [migration/6] root 15 1 0 18:56 ? 00:00:00 [ksoftirqd/6] root 16 1 0 18:56 ? 00:00:00 [migration/7] root 17 1 0 18:56 ? 00:00:00 [ksoftirqd/7] root 18 1 0 18:56 ? 00:00:00 [migration/8] root 19 1 0 18:56 ? 00:00:00 [ksoftirqd/8] root 20 1 0 18:56 ? 00:00:00 [migration/9] root 21 1 0 18:56 ? 00:00:00 [ksoftirqd/9] root 22 1 0 18:56 ? 00:00:00 [migration/10] root 23 1 0 18:56 ? 00:00:00 [ksoftirqd/10] root 24 1 0 18:56 ? 00:00:00 [migration/11] root 25 1 0 18:56 ? 00:00:00 [ksoftirqd/11] root 26 1 0 18:56 ? 00:00:00 [migration/12] root 27 1 0 18:56 ? 00:00:00 [ksoftirqd/12] root 28 1 0 18:56 ? 00:00:00 [migration/13] root 29 1 0 18:56 ? 00:00:00 [ksoftirqd/13] root 30 1 0 18:56 ? 00:00:00 [migration/14] root 31 1 0 18:56 ? 00:00:00 [ksoftirqd/14] root 32 1 0 18:56 ? 00:00:00 [migration/15] root 33 1 0 18:56 ? 00:00:00 [ksoftirqd/15] root 34 1 0 18:56 ? 00:00:00 [migration/16] root 35 1 0 18:56 ? 00:00:00 [ksoftirqd/16] root 36 1 0 18:56 ? 00:00:00 [migration/17] root 37 1 0 18:56 ? 00:00:00 [ksoftirqd/17] root 38 1 0 18:56 ? 00:00:00 [migration/18] root 39 1 0 18:56 ? 00:00:00 [ksoftirqd/18] root 40 1 0 18:56 ? 00:00:00 [migration/19] root 41 1 0 18:56 ? 00:00:00 [ksoftirqd/19] root 42 1 0 18:56 ? 00:00:00 [migration/20] root 43 1 0 18:56 ? 00:00:00 [ksoftirqd/20] root 44 1 0 18:56 ? 00:00:00 [migration/21] root 45 1 0 18:56 ? 00:00:00 [ksoftirqd/21] root 46 1 0 18:56 ? 00:00:00 [migration/22] root 47 1 0 18:56 ? 00:00:00 [ksoftirqd/22] root 48 1 0 18:56 ? 00:00:00 [migration/23] root 49 1 0 18:56 ? 00:00:00 [ksoftirqd/23] root 50 1 0 18:56 ? 00:00:00 [migration/24] root 51 1 0 18:56 ? 00:00:00 [ksoftirqd/24] root 52 1 0 18:56 ? 00:00:00 [migration/25] root 53 1 0 18:56 ? 00:00:00 [ksoftirqd/25] root 54 1 0 18:56 ? 00:00:00 [migration/26] root 55 1 0 18:56 ? 00:00:00 [ksoftirqd/26] root 56 1 0 18:56 ? 00:00:00 [migration/27] root 57 1 0 18:56 ? 00:00:00 [ksoftirqd/27] root 58 1 0 18:56 ? 00:00:00 [migration/28] root 59 1 0 18:56 ? 00:00:00 [ksoftirqd/28] root 60 1 0 18:56 ? 00:00:00 [migration/29] root 61 1 0 18:56 ? 00:00:00 [ksoftirqd/29] root 62 1 0 18:56 ? 00:00:00 [migration/30] root 63 1 0 18:56 ? 00:00:00 [ksoftirqd/30] root 64 1 0 18:56 ? 00:00:00 [migration/31] root 65 1 0 18:56 ? 00:00:00 [ksoftirqd/31] root 66 1 0 18:56 ? 00:00:00 [events/0] root 67 1 0 18:56 ? 00:00:00 [events/1] root 68 1 0 18:56 ? 00:00:00 [events/2] root 69 1 0 18:56 ? 00:00:00 [events/3] root 70 1 0 18:56 ? 00:00:00 [events/4] root 71 1 0 18:56 ? 00:00:00 [events/5] root 72 1 0 18:56 ? 00:00:00 [events/6] root 73 1 0 18:56 ? 00:00:00 [events/7] root 74 1 0 18:56 ? 00:00:00 [events/8] root 75 1 0 18:56 ? 00:00:00 [events/9] root 76 1 0 18:56 ? 00:00:00 [events/10] root 77 1 0 18:56 ? 00:00:00 [events/11] root 78 1 0 18:56 ? 00:00:00 [events/12] root 79 1 0 18:56 ? 00:00:00 [events/13] root 80 1 0 18:56 ? 00:00:00 [events/14] root 81 1 0 18:56 ? 00:00:00 [events/15] root 82 1 0 18:56 ? 00:00:00 [events/16] root 83 1 0 18:56 ? 00:00:00 [events/17] root 84 1 0 18:56 ? 00:00:00 [events/18] root 85 1 0 18:56 ? 00:00:00 [events/19] root 86 1 0 18:56 ? 00:00:00 [events/20] root 87 1 0 18:56 ? 00:00:00 [events/21] root 88 1 0 18:56 ? 00:00:00 [events/22] root 89 1 0 18:56 ? 00:00:00 [events/23] root 90 1 0 18:56 ? 00:00:00 [events/24] root 91 1 0 18:56 ? 00:00:00 [events/25] root 92 1 0 18:56 ? 00:00:00 [events/26] root 93 1 0 18:56 ? 00:00:00 [events/27] root 94 1 0 18:56 ? 00:00:00 [events/28] root 95 1 0 18:56 ? 00:00:00 [events/29] root 96 1 0 18:56 ? 00:00:00 [events/30] root 97 1 0 18:56 ? 00:00:00 [events/31] root 105 1 0 18:56 ? 00:00:00 [kswapd0] root 104 1 0 18:56 ? 00:00:00 [kswapd1] root 103 1 0 18:56 ? 00:00:00 [kswapd2] root 102 1 0 18:56 ? 00:00:00 [kswapd3] root 100 1 0 18:56 ? 00:00:00 [kswapd5] root 101 1 0 18:56 ? 00:00:00 [kswapd4] root 99 1 0 18:56 ? 00:00:00 [kswapd6] root 98 1 0 18:56 ? 00:00:00 [kswapd7] root 106 1 1 18:56 ? 00:00:03 [pdflush] root 107 1 1 18:56 ? 00:00:03 [pdflush] root 108 1 0 18:56 ? 00:00:00 [aio/0] root 109 1 0 18:56 ? 00:00:00 [aio/1] root 110 1 0 18:56 ? 00:00:00 [aio/2] root 111 1 0 18:56 ? 00:00:00 [aio/3] root 112 1 0 18:56 ? 00:00:00 [aio/4] root 113 1 0 18:56 ? 00:00:00 [aio/5] root 114 1 0 18:56 ? 00:00:00 [aio/6] root 115 1 0 18:56 ? 00:00:00 [aio/7] root 116 1 0 18:56 ? 00:00:00 [aio/8] root 117 1 0 18:56 ? 00:00:00 [aio/9] root 118 1 0 18:56 ? 00:00:00 [aio/10] root 119 1 0 18:56 ? 00:00:00 [aio/11] root 120 1 0 18:56 ? 00:00:00 [aio/12] root 121 1 0 18:56 ? 00:00:00 [aio/13] root 122 1 0 18:56 ? 00:00:00 [aio/14] root 123 1 0 18:56 ? 00:00:00 [aio/15] root 124 1 0 18:56 ? 00:00:00 [aio/16] root 125 1 0 18:56 ? 00:00:00 [aio/17] root 126 1 0 18:56 ? 00:00:00 [aio/18] root 127 1 0 18:56 ? 00:00:00 [aio/19] root 128 1 0 18:56 ? 00:00:00 [aio/20] root 129 1 0 18:56 ? 00:00:00 [aio/21] root 130 1 0 18:56 ? 00:00:00 [aio/22] root 131 1 0 18:56 ? 00:00:00 [aio/23] root 132 1 0 18:56 ? 00:00:00 [aio/24] root 133 1 0 18:56 ? 00:00:00 [aio/25] root 134 1 0 18:56 ? 00:00:00 [aio/26] root 135 1 0 18:56 ? 00:00:00 [aio/27] root 136 1 0 18:56 ? 00:00:00 [aio/28] root 137 1 0 18:56 ? 00:00:00 [aio/29] root 138 1 0 18:56 ? 00:00:00 [aio/30] root 139 1 0 18:56 ? 00:00:00 [aio/31] root 140 1 0 18:56 ? 00:00:00 [scsi_eh_0] root 320 1 0 18:56 ? 00:00:00 /sbin/syslogd root 323 1 0 18:56 ? 00:00:00 /sbin/klogd root 330 1 0 18:56 ? 00:00:00 /usr/sbin/inetd root 334 1 0 18:56 ? 00:00:00 /usr/sbin/netserver root 340 1 0 18:56 ? 00:00:00 /usr/sbin/sshd root 343 1 0 18:56 ? 00:00:00 /usr/sbin/ntpd root 346 1 0 18:56 tty1 00:00:00 /sbin/getty 38400 tty1 root 347 1 0 18:56 tty2 00:00:00 /sbin/getty 38400 tty2 root 348 1 0 18:56 tty3 00:00:00 /sbin/getty 38400 tty3 root 349 1 0 18:56 tty4 00:00:00 /sbin/getty 38400 tty4 root 350 1 0 18:56 tty5 00:00:00 /sbin/getty 38400 tty5 root 351 1 0 18:56 tty6 00:00:00 /sbin/getty 38400 tty6 root 352 1 0 18:56 ttyS0 00:00:00 -bash root 354 340 0 18:57 ? 00:00:00 /usr/sbin/sshd wli 356 354 0 18:57 ? 00:00:00 /usr/sbin/sshd wli 357 356 0 18:57 pts/0 00:00:00 -zsh root 360 340 0 18:57 ? 00:00:00 /usr/sbin/sshd wli 362 360 0 18:57 ? 00:00:00 /usr/sbin/sshd wli 363 362 0 18:57 pts/1 00:00:00 -zsh root 366 340 0 18:57 ? 00:00:00 /usr/sbin/sshd wli 368 366 0 18:57 ? 00:00:00 /usr/sbin/sshd wli 369 368 0 18:57 pts/2 00:00:00 -zsh wli 4435 363 0 18:59 pts/1 00:00:00 ps -fade wli 4436 363 0 18:59 pts/1 00:00:00 less
Hmm, is there any hope left for state machines?
Bill
P.S.: I'd also love to see make -j64 bzImage take 26s like on 16x
instead of 48s as it appears to be doing on 32x. Doubling num_cpus_online() shouldn't double kernel kernel compile time.
Bill - so what happens if you trim down the aio, event and ksoftirqd threads to a sane size (you might also want to do something about the fact 2.5 still runs ksoftirq too easily). Intuitively I'd go for a square root of the number of processors + 1 sort of function but what do the benchmarks say ?
Quoted 5 lines · Alan Cox
Bill - so what happens if you trim down the aio, event and ksoftirqd threads to a sane size (you might also want to do something about the fact 2.5 still runs ksoftirq too easily). Intuitively I'd go for a square root of the number of processors + 1 sort of function but what do the benchmarks say ?
IMO having various threads per-CPU is getting silly for (say) 4+ CPUs. Even for two CPUs it means quite a good number of kernel threads.
Does anyone really know for certain that this is necessary versus having few per-CPU threads calling into state-machine functions?
--cw
Quoted 5 lines · Alan Cox
Bill - so what happens if you trim down the aio, event and ksoftirqd threads to a sane size (you might also want to do something about the fact 2.5 still runs ksoftirq too easily). Intuitively I'd go for a square root of the number of processors + 1 sort of function but what do the benchmarks say ?
Both reorganizing the per-cpu thread pools as state machines and inserting new locking look like work-intensive projects...
It's not become explosively bad yet (1MB of overhead is eyebrow-raising but not particularly damaging) so there's no rush to trim this down, but I'm at least thinking about doing this later. One of the major obstacles for the state machine approach is that the migration threads run at RT priority while the rest do not, and of course the greater than per-cpu granularity approach suffers from additional locking.
Bill