Re: [PATCH]sched: Isochronous class v2 for unprivileged soft rtscheduling
From: utz lehmann
Date: Wed Jan 19 2005 - 19:30:13 EST
Hi Con
On Thu, 2005-01-20 at 09:39 +1100, Con Kolivas wrote:
> This is version 2 of the SCHED_ISO patch with the yield bug fixed and
> code cleanups.
Thanks for the update.
@@ -2406,6 +2489,10 @@ void scheduler_tick(void)
task_t *p = current;
rq->timestamp_last_tick = sched_clock();
+ if (iso_task(p) && !rq->iso_refractory)
+ inc_iso_ticks(rq, p);
+ else
+ dec_iso_ticks(rq, p);
scheduler_tick() is not only called by the timer interrupt but also form
the fork code. Is this intended? I think the accounting for
iso_refractory is wrong. Isn't calling it from
timer.c::update_process_times() better?
And shouldn't real RT task also counted? If RT tasks use 40% cpu you can
lockup the system as unprivileged user with SCHED_ISO because it doesn't
reach the 70% cpu limit.
Futher on i see a fundamental problem with this accounting for
iso_refractory. What if i manage as unprivileged user to run a SCHED_ISO
task which consumes all cpu and only sleeps very short during the timer
interrupt? I think this will nearly lockup or very slow down the system.
The iso_cpu limit can't guaranteed.
My simple yield DoS don't work anymore. But i found another way.
Running this as SCHED_ISO:
#include <stdio.h>
#include <unistd.h>
#include <sched.h>
#include <sys/time.h>
#include <sys/resource.h>
struct timeval tv;
int a, b, i0, i1;
int cpuusage ()
{
struct rusage ru;
getrusage(RUSAGE_SELF, &ru);
return ru.ru_utime.tv_usec + ru.ru_stime.tv_usec;
}
int main ()
{
while(1) {
a = tv.tv_sec;
b = tv.tv_usec;
gettimeofday(&tv, 0);
i0 = i1;
i1 = cpuusage();
if (i0 != i1) {
// printf("%d.%06d\t%d.%06d\t%d\t%d\n",
// a, b, (int)tv.tv_sec, (int)tv.tv_usec, i0, i1);
}
}
}
It stalled the system for a few seconds and the drop it to SCHED_OTHER.
Then start a additional SCHED_OTHER cpu hog (while true; do : ; done).
The system locks up after a few seconds.
sysrq-n causes a reboot.
utz
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/