On Tue, Jun 29, 2010 at 4:13 AM, Simon Li <simon.jiyou@xxxxxxxxx> wrote: > We have one process(Streaming server) R/W disks, and another process > is a pure monitoring process of the streaming server, periodicially > collecting aliveness info from the streaming process. At the time of > _"I called kernel temporary hung"_, the streaming process "looks" > entering into stuck as no more logs prints(usually, there are dozens > of logs prints in each second), this also exactly happened to the > monitoring process, and the sys log as well. At the time of _"kernel > hung resumed"_, the two process suddenly came back to run(Ye, observed > from log printings) and running as usual. > > A full syslog attached, you can do _grep_ "[RSS-RAW] Failed to read", > the results indicate "kernel hung" frequently occurred during those > read() syscalls. If the process or syslog is writing its logs to disk, then eventually after the kernel decides that too much data has been queued up to be written to disk, those processes trying to write will block until some of the data can be written out. If all disk I/O is stalled, then a lot of things can more or less grind to a halt. The kernel is not hung, but userspace may be effectively hung. > > > On Tue, Jun 29, 2010 at 3:29 PM, Tejun Heo <htejun@xxxxxxxxx> wrote: >> On 06/29/2010 09:27 AM, Simon Li wrote: >>> "stuck" here I mean, the kernel stuck inside kernel, so applications >>> got stuck as well... >> >> How did you determine that? Come on. Give us some data. >> >> -- >> tejun >> > -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
