| Summary: | DAHLIN-00198: High CPU utlization by ksoftirqd since enabling of internal timing in r8053 | ||
| Reporter: | Sean Bright (seanbright) | Labels: | |
| Date Opened: | 2010-07-10 13:22:54 | Date Closed: | 2010-07-12 13:45:04 |
| Priority: | Minor | Regression? | No |
| Status: | Closed/Complete | Components: | dahdi (the module) |
| Versions: | 2.3.0 | Frequency of Occurrence | |
| Related Issues: | |||
| Environment: | Attachments: | ||
| Description: | Running on a Dell PowerEdge R610 with 2 TCE400B transcoder cards. Also reproducible on a Dell PowerEdge T310 with no DAHDI hardware at all. 'top' shows ksoftirqd taking up 30-60% of CPU once dahdi is loaded and load average rises, even without asterisk loaded. Before r8053, this problem does not manifest. I have marked this bug as affecting 2.3.0, but I have tested with dahdi-linux/trunk and it is still occurring. Please let me know what other information I can provide. | ||
| Comments: | By: Shaun Ruffell (sruffell) 2010-07-10 22:42:14 seanbright: What kernel / distribution are you running? Also, are you running ntpd on this system? The rate at which interrupts are 'generated' depends on wall time with the core timer. So, if the time is actively being adjusted after loading DAHDI, it is possible for the load to go up since 'process_masterspan' is being called more frequently than it should in that case. If you think time adjustment is possibly related on your system, could you make sure ntpdate is run before ntp, and both are started before DAHDI? By: Sean Bright (seanbright) 2010-07-11 13:10:04 <pre> user@host:~$ uname -a Linux host.localdomain 2.6.32-23-server ASTERISK-33-Ubuntu SMP Fri Jun 11 09:11:11 UTC 2010 x86_64 GNU/Linux user@host:~$ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 10.04 LTS Release: 10.04 Codename: lucid </pre> ntpd is not running on this system. By: Shaun Ruffell (sruffell) 2010-07-11 13:16:51 Is the system able to keep accurate wall time? By: Sean Bright (seanbright) 2010-07-11 14:39:00 It appears to be able to, yes. By: Digium Subversion (svnbot) 2010-07-12 13:45:03 Repository: dahdi Revision: 8868 U linux/trunk/drivers/dahdi/dahdi-base.c U linux/trunk/drivers/dahdi/dahdi_dummy.c ------------------------------------------------------------------------ r8868 | sruffell | 2010-07-12 13:45:02 -0500 (Mon, 12 Jul 2010) | 12 lines dahdi: Explicitly ensure we don't schedule a timer for the current tick. As best as I can tell, when CONFIG_NO_HZ is set along with CONFIG_HZ < 250, it is possible for the system timer to exceed MAX_SOFTIRQ_RESTART. Tony Mountifield alluded that this might be a problem in the below mailing list posting, but when I was originally testing, I wasn't using CONFIG_NO_HZ and HZ < 250. http://www.mail-archive.com/asterisk-dev@lists.digium.com/msg37384.html (closes issue DAHLIN-198) Reported by: seanbright ------------------------------------------------------------------------ http://svn.digium.com/view/dahdi?view=rev&revision=8868 | ||