I had experimented with throttling runaway RT tasks. I use a similar
accounting. I saw a difference between counting with or without the
calling from fork. If i remember correctly the timeout expired too fast
if the non-RT load was "while /bin/true; do :; done".
With "while true; do :; done" ("true" is bash buildin) it worked good.
But maybe it's not important in the real world.
It won't be relevant if we move to a sched_clock() based timesource anyway, which looks to be the next major development for this.
If i understand sched_clock correctly it only has higher resolution if you can use tsc. In the non tsc case it's jiffies based. (On x86). I think you can easily fool a timer tick/jiffies based accounting and do a local DoS.
The same timer is used for accounting of SCHED_NORMAL tasks, so if you can work around that you can DoS the system with even the correct combination of SCHED_NORMAL tasks. When Ingo implemented sched_clock all the architectures slowly came on board. If I recall correctly the lowest resolution one still had microsecond accuracy which is more than enough given the time a context switch takes.
Making SCHED_ISO privileged if you don't have a high resolution sched_clock is ugly. I really like the idea of a unprivileged SCHED_ISO but it has to be safe for a multi user system. And the kernel default should be safe for multi user.
Agreed; this is exactly what this work is about.
Cheers, Con - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
