Chris Wedgwood [[email protected]] wrote:
> My changes are pretty small and don't oops. Like I said though,
> something just isn't quite right though :)
Yes indeed, your patch works fine, but as you observed, it hangs
sometimes. My guess is the work queue work isn't getting done on time.
If you give the [nvisr/0] process a negative priority, the stalls go
away. I just played through a level of Chromium BSU and it performed
flawlessly (with the nvisr process at -20 priority). With the latest bk
tree there are also no oopses.
I'm not sure how to solve this in a general way. But the nvisr work
isn't getting done quickly enough. I think under the task queue system
the bottom-half interrupt work got scheduled as immediate (i.e. it's
guaranteed to be the next work run). But under work queues it enters
the scheduler like any other process, so several timeslices can pass
before it gets done.
Really, the nvisr process should be SCHED_FIFO. (i think) Or whatever
it takes to ensure that when it is given work, it gets scheduled
immediately.
Correct me if I'm wrong...I know diddly squat about task/work queues/bh
isr's...
I'm re-sending your patch against the nvidia driver with this post and
copying it to lkml, since it works great and others might want to see
what the code does.
Cheers,
-- Bob
Bob McElrath
Univ. of Wisconsin at Madison, Department of Physics
"The purpose of separation of church and state is to keep forever from
these shores the ceaseless strife that has soaked the soil of Europe in
blood for centuries." -- James Madison
Bob McElrath [[email protected]] wrote:
> If you give the [nvisr/0] process a negative priority, the stalls go
> away. I just played through a level of Chromium BSU and it performed
> flawlessly (with the nvisr process at -20 priority). With the latest bk
> tree there are also no oopses.
So it seems the way to do this is:
my_workqueue = create_workqueue("mywork");
if (!my_workqueue) {
printk("Unable to create workqueue\n");
return -EIO;
}
pri.sched_priority = 1; /* BM: any nonzero should do, is there any reason
to chose a larger priority? */
rc = security_ops->task_setscheduler(isr_workqueue->cpu_wq[0]->pid, SCHED_FIFO, &pri);
if(rc < 0) {
printk("Unable to set real-time priority for NV (err=%d)\n", rc);
}
The above code doesn't work though because the struct workqueue_struct is
hidden away in workqueue.c, invisible to modules. The line:
isr_workqueue->cpu_wq[0]->pid
bombs because the struct is not defined (dereferencing pointer to incomplete
type). Is there a better way to get the pid of a workqueue I just created? Or
for that matter is there a better way to set the scheduler for a workqueue I
just created? I imagine many drivers would want to do this...
I notice the sched_setscheduler system call is not available in any kernel
header. What is the proper procedure for calling such a function from a
module?
Cheers,
-- Bob
Bob McElrath
Univ. of Wisconsin at Madison, Department of Physics
"The purpose of separation of church and state is to keep forever from
these shores the ceaseless strife that has soaked the soil of Europe in
blood for centuries." -- James Madison