Am Mittwoch, 8. Januar 2014, 11:40:36 schrieb Hudson Flavio Meneses Lacerda:
> Hi.

Hi Hudson,

> Sometimes, the system raises a lot of processes, causing considerable
> delay to respond any input action. This moment, there are 312 processes
> running (in a personal laptop - Debian testing). Here is a partial view
> of "top":
> 
> [...]
>     1 root      20   0  2880  636  600 S  0,0  0,1   0:00.92 init
>     2 root      20   0     0    0    0 S  0,0  0,0   0:00.00 kthreadd
>     5 root       0 -20     0    0    0 S  0,0  0,0   0:00.00 kworker/0:0H
>     7 root      rt   0     0    0    0 S  0,0  0,0   0:00.00 posixcputmr/0
>     8 root      20   0     0    0    0 S  0,0  0,0   0:00.00 kclksetdelayd
>     9 root      20   0     0    0    0 S  0,0  0,0   0:00.00 kcmosdelayd
>    10 root      rt   0     0    0    0 S  0,0  0,0   0:00.00 migration/0
>    11 root      20   0     0    0    0 S  0,0  0,0   0:00.12 rcu_preempt
>    12 root      20   0     0    0    0 S  0,0  0,0   0:00.00 rcu_bh
>    13 root      20   0     0    0    0 S  0,0  0,0   0:00.00 rcu_sched
>    14 root      rt   0     0    0    0 S  0,0  0,0   0:00.00 watchdog/0
>    15 root       0 -20     0    0    0 S  0,0  0,0   0:00.00 khelper
>    16 root      20   0     0    0    0 S  0,0  0,0   0:00.00 kdevtmpfs
>    17 root       0 -20     0    0    0 S  0,0  0,0   0:00.00 netns
>    18 root       0 -20     0    0    0 S  0,0  0,0   0:00.00 writeback
>    19 root       0 -20     0    0    0 S  0,0  0,0   0:00.00 kintegrityd
>    20 root       0 -20     0    0    0 S  0,0  0,0   0:00.00 bioset
>    21 root       0 -20     0    0    0 S  0,0  0,0   0:00.00 kblockd
>    22 root     -51   0     0    0    0 S  0,0  0,0   0:00.20 irq/10-acpi
>    23 root      20   0     0    0    0 S  0,0  0,0   0:00.25 kworker/0:1
>    24 root      20   0     0    0    0 S  0,0  0,0   0:00.00 khungtaskd
>    25 root      20   0     0    0    0 S  0,0  0,0   0:00.48 kswapd0
>    26 root      25   5     0    0    0 S  0,0  0,0   0:00.00 ksmd
>    27 root      20   0     0    0    0 S  0,0  0,0   0:00.00 fsnotify_mark
>    28 root       0 -20     0    0    0 S  0,0  0,0   0:00.00 crypto
>    33 root       0 -20     0    0    0 S  0,0  0,0   0:00.00 kthrotld
>    36 root     -76   0     0    0    0 S  0,0  0,0   0:00.03 irq/1-i8042
>    37 root     -91   0     0    0    0 S  0,0  0,0   0:00.00 irq/8-rtc0
>    38 root      20   0     0    0    0 S  0,0  0,0   0:00.00 mce-notify
>    39 root       0 -20     0    0    0 S  0,0  0,0   0:00.00 deferwq
>    43 root      20   0     0    0    0 S  0,0  0,0   0:00.00 kworker/0:2
>   135 root      20   0     0    0    0 S  0,0  0,0   0:00.00 khubd
>   136 root       0 -20     0    0    0 S  0,0  0,0   0:00.00 ata_sff
>   137 root     -81   0     0    0    0 S  0,0  0,0   0:00.00 irq/20-uhci_hcd
> 138 root     -51   0     0    0    0 S  0,0  0,0   0:00.12 irq/21-ehci_hcd
> 144 root     -51   0     0    0    0 S  0,0  0,0   0:00.00 irq/17-mmc0
> [...]
> 
> 
> What causes this large amount of simultaneous services? How to select
> only the essential ones, or make them run distributed in time, so that
> they do not overload the processor?

If you relate the values displayed to their headings (which ps displays in the 
first lines and which you omitted), you will find that none of these are even 
close to overloading a processor. Most didn“t use any noteworthy amount of CPU 
time at all.

These are all kernel threads and I never worried on the amount of these:

merkaba:~> ps aux | grep "[0-9] \[" | grep root | wc -l
137

on this ThinkPad T520, but what gives? None of these cause a problem here.

Additionally your kernel seems to use threaded interrupts, which as to my 
knowledge is not a standard setting. Do you use a realtime kernel? 
"threadirqs" may cause strange issues from time to time, such as with 3.13 a 
straight lockup on accessing a SD card via MMC based internal card reader or 
breaking USB on another setup.

So or so, if you really want to worry about kernel threads, then I suggest you 
learn a bit more about these and also about the output os ps so that you can 
see that above quoted kernel threads no not load your CPUs at all to any 
noteworthy amount.

If you have performance issues then I suggest describing what these are in as 
much detail as possible instead of just picking any even remotely possible 
culprit after another to eventually find out their cause.

Then check each resource in your system for utilization and saturation to see 
which resources are overloaded. And then go into detail.

Ciao,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4559029.i9gv5Prb8N@merkaba

Reply via email to