| Title: | DIGITAL UNIX (FORMERLY KNOWN AS DEC OSF/1) |
| Notice: | Welcome to the Digital UNIX Conference |
| Moderator: | SMURF::DENHAM |
| Created: | Thu Mar 16 1995 |
| Last Modified: | Fri Jun 06 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 10068 |
| Total number of notes: | 35879 |
The problem that we are seeing is that our high-priority multi-threaded application is being preempted from doing disk reads by a normal user-level rcp or cp command. The question is, how can we code our application so that it not only has CPU scheduling priority, but also disk I/O priority. I have explored in detail all possibilities that I am familiar with in terms of coding the app. The threads run at FIFO scheduling method with PRI_FIFO_MAX priority. I have tried using normal file 'read' calls as well as coding aio_read/aio_suspend/aio_error/aio_return sequences. I tried to set the aio_prio to AIO_PRIO_MAX but it looks like its not yet implemented (it does say that is isn't implemented in the man page but I was just wishing for magic). When the application is running normally, it performs consecutive 1Mb reads straight through an MPEG-2 video clip file. When nothing else is accessing the disk (one physical disk with either UFS or Advfs) it reads the 1Mb blob in about 120 millisecs. When we start an rcp or cp to or from the same disk, our application's disk reads slow down to 1Mb in about 600 millisecs. This behavior seems to happen no matter how I 'nice' the rcp or cp command (I can see from various ps commands that I am in fact changing the priorities). So the $64K question is, how can we make the cp/rcp commands back off when our app needs disk access or conversely, how can we make our app preempt the rcp/cp commands. Any help would be greatly appreciated
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 8937.1 | COL01::LINNARTZ | Mon Feb 24 1997 12:05 | 12 | ||
It's some time ago I tried to look at this. Here is my conclusion
somebody with more insight might correct me.
The priorities you're changing are the process prio's.
Those get changed and worked on, but the prio's you want to
get changed are those of the CAM subsystem. For me it turned out
that they always are set to the same prio. so essentially i think
the only way to get this changed is filing a QAR/IPMT with the request
that the cam subsystem thread priority has to reflect the process
prio values. And I think that's not an easy task, so hopefully I'm
wrong.
Pit
| |||||
| 8937.2 | SMURF::DENHAM | Digital UNIX Kernel | Mon Feb 24 1997 14:35 | 6 | |
BTW, we have no plans to implement the AIO PRIO stuff from the
realtime standard. Extremely costly to implement on our system
and the standard has a number of flaws/amibiguities as well.
We even convinced X/OPEN, which is standardizing the RT stuff
for UNIX98 to agree and leave prio I/O out of the required
RT section....
| |||||