On Wednesday 14 March 2007 07:58, Con Kolivas wrote:
quoted text
> On Wednesday 14 March 2007 03:03, Con Kolivas wrote:
> > On Wednesday 14 March 2007 02:31, Con Kolivas wrote:
> > > On Monday 12 March 2007 22:26, Al Boldi wrote:
> > > > I think, it should be possible to spread this max expiration latency
> > > > across the rotation, should it not?
> > >
> > > Can you try the attached patch please Al and Mike? It "dithers" the
> > > priority bitmap which tends to fluctuate the latency a lot more but in
> > > a cyclical fashion. This tends to make the max latency bound to a
> > > smaller value and should make it possible to run -nice tasks without
> > > killing the latency of the non niced tasks. Eg you could possibly run X
> > > nice -10 at a guess like we used to in 2.4 days. It's not essential of
> > > course, but is a workaround for Mike's testcase.
> >
> > Oops, one tiny fix. This is a respin of the patch, sorry.

quoted text
> Bah with a bit more sleep under my belt it became clear that I forgot to
> update the expired array in any proper way so this change almost breaks
> stuff at the moment in the shape it's in. Please disregard this change for
> now apart from interest in how I'm tackling the nice issue.

The rsdl patches queued up so far are stable and boot fine and are reasonably 
performant on many architectures so I'm quite happy for them to get a run 
in -mm. The changes planned will (as you may have seen on this email thread) 
decrease average latencies across all nice levels, and make differential nice 
levels run better together. This will allow -nice to be used without 
significant latency harm to not niced tasks (as there is presently in rsdl 
and mainline). The change required on top of the patch earlier in this email 
is to make the dynamic bitmap reflect where the tasks will actually be on an 
array swap.

However, I must inform people that I have to arrest the RSDL development for 
at least this week. I have a new and fairly serious neck problem that is 
being exacerbated badly by sitting in front of the computer for any extended 
period.

I suspect the inner workings of RSDL currently are not well understood yet by 
anyone else well enough to hack on it. I'm not at all opposed to someone 
taking up the code at the moment and making the necessary changes I've 
mentioned above in the meantime though if they can get their head around it.

-- 
-ck
-
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/