Re: [PATCH]sched: Isochronous class v2 for unprivileged soft rt scheduling

[Con Kolivas]

utz lehmann wrote:
> On Sat, 2005-01-22 at 10:48 +1100, Con Kolivas wrote:
>
> > utz lehmann wrote:
> >
> > > Hi
> > >
> > > I dislike the behavior of the SCHED_ISO patch that iso tasks are
> > > degraded to SCHED_NORMAL if they exceed the limit.
> > > IMHO it's better to throttle them at the iso_cpu limit.
> > >
> > > I have modified Con's iso2 patch to do this. If iso_cpu > 50 iso tasks
> > > only get stalled for 1 tick (1ms on x86).
> >
> > Some tasks are so cache intensive they would make almost no forward 
> > progress running for only 1ms.
>
>
> Ok. The throttle duration can be exceed.
> What is a good value? 5ms, 10ms?

It's architecture and cpu dependant. Useful timeslices to avoid cache 
trashing vary from 2ms to 20ms. Also HZ varies between architectures and 
setups, and almost certainly will vary in some dynamic way in the future 
altering substantially the accuracy of such a setup.

> > > Fortunately there is a currently unused task prio (MAX_RT_PRIO-1) [1]. I
> >
> > Your implementation is not correct. The "prio" field of real time tasks 
> > is determined by MAX_RT_PRIO-1-rt_priority. Therefore you're limiting 
> > the best real time priority, not the other way around.
>
>
> Really? The task prios are (lower value is higher priority):
>
> 0
> ..			For SCHED_FIFO/SCHED_RR (rt_priority 99..1)
> 98	MAX_RT_PRIO-2
>
> 99	MAX_RT_PRIO-1 	ISO_PRIO (rt_priority 0)	
>
> 100	MAX_RT_PRIO
> ..			For SCHED_NORMAL
> 139	MAX_PRIO-1
>
> ISO_PRIO is between the SCHED_FIFO/SCHED_RR and the SCHED_NORMAL range.

I wan't debating that fact. I was saying that decreasing the range of 
priorities you can have for real time will lose the highest priority ones.

	if (SCHED_RT(policy))
		p->prio = MAX_USER_RT_PRIO-1 - p->rt_priority;

> > Throttling them for only 1ms will make it very easy to starve the system 
> >  with 1 or more short running (<1ms) SCHED_NORMAL tasks running. Lower 
> > priority tasks will never run.

can I also comment on:
+	while (!list_empty(queue)) {
+		next = list_entry(queue->next, task_t, run_list);
+		dequeue_task(next, active);
+		enqueue_task(next, expired);
+	}

O(n) functions are a bad idea in critical codepaths, even if they only 
get hit when there is more than one SCHED_ISO task queued.

Apart from those, I'm not really sure what advantage this different 
design has. Once you go over the cpu limit the behaviour is grey and 
your design basically complicates what is already simple - to make an 
unprivileged task starvation free you run it SCHED_NORMAL. I know you 
want it back to high priority as soon as possible, but I fail to see how 
this is any better. They're either real time or not depending on what 
limits you set in either design.

As for priority support, I have been working on it. While the test cases 
I've been involved in show no need for it, I can understand why it would 
be desirable.

Cheers,
Con

Attachment: signature.asc
Description: OpenPGP digital signature