2004-11-10 16:31:38

by Dean Nelson

[permalink] [raw]
Subject: kthread realtime priorities and exporting sys_sched_setscheduler()

I'm trying to push XP[C|NET] out to the community. (For further details:
http://marc.theaimsgroup.com/?l=linux-ia64&m=109337050919186&w=2 )

An objection was raised over the exporting and calling of
sys_sched_setscheduler(), which XPC calls to make its kthreads
run at realtime priorities. Without this change we found that it
was possible for user processes to be given a higher effective
priority than the kthreads used by XPC. The upshot of this was
that the latencies incurred by XPC increased 300 times in the
test example given. If XPC's kthreads were given realtime
priorities this did not happen. (For further details:
http://marc.theaimsgroup.com/?l=linux-ia64&m=109337503100067&w=2 )

Note that XPC uses kthreads because it is possible for them to block
indefinitely.

So if we are unable to export sys_sched_setscheduler() or setscheduler()
what would you suggest we do to solve this particular problem?

Thanks,
Dean


2004-11-10 19:15:10

by Andrew Morton

[permalink] [raw]
Subject: Re: kthread realtime priorities and exporting sys_sched_setscheduler()

[email protected] (Dean Nelson) wrote:
>
> I'm trying to push XP[C|NET] out to the community. (For further details:
> http://marc.theaimsgroup.com/?l=linux-ia64&m=109337050919186&w=2 )
>
> An objection was raised over the exporting and calling of
> sys_sched_setscheduler(), which XPC calls to make its kthreads
> run at realtime priorities. Without this change we found that it
> was possible for user processes to be given a higher effective
> priority than the kthreads used by XPC. The upshot of this was
> that the latencies incurred by XPC increased 300 times in the
> test example given. If XPC's kthreads were given realtime
> priorities this did not happen. (For further details:
> http://marc.theaimsgroup.com/?l=linux-ia64&m=109337503100067&w=2 )

I'd disagree with Christoph on that. Being able to set the scheduling
policy from a module-based kernel thread is a sensible thing to be able to
do, and you can do it by issuing a direct trap anyway.

EXPORT_SYMBOL_GPL() would be preferred.

Possibly it could be done by adding a variant of kthread_create() which has
a new `policy' argument, but it doesn't really seem worth the fuss.