lkml.org 
[lkml]   [2003]   [Jul]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectHowto check for slow io-operations
Hello,

sorry, if this is a little bit off-topic but I don't known where else to
ask for!

The following situation is given:
An executable uses a small :-) number of (POSIX-)threads. One of them is
the "input-thread" that blocks on select and delivers incoming data to a
reentrant queue. I need this thread to avoid a too high dropping rate for
udp data! A "processing-thread" reads the items from the queue and does
the "real" processing. I detected that the "input-thread" seems to be
potentially much faster than the "processing-thread" but under normal
load, I thought, this effect is regulated by the scheduler since busy
processes with SCHED_OTHER should have a higher priority than the
idle-process :-).
Unfortunately even under such conditions the number of items in the
internal queue between the "input-thread" and the "processing-thread"
increases continuously. Strange is, that the evaluation of /proc/stat and
/proc/loadavg showed idle schedules between 70 and 90 percent.

How is this possible?

The only thing I could imagine is that the "processing-thread" is not
really busy but waits for the completion of some slow input/output
operations. Anyway - in this case it would be important to me to identify
this slow input/output operations.

Does the kernel provide any logging facilities related to this
identification?

Or does anbody know a solution for the original problem?

I use the following environment:
Red Hat Linux 8.0 3.2-7 with Linux version 2.4.18-14

Much thanks
Andreas

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:46    [W:0.019 / U:0.284 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site