RE: [Lse-tech] RE: 10/1 LSE call topics: Cpusets and real-time app needs.

[Gross, M. <mar...@in...>]

> -----Original Message-----
> From: Andi Kleen [mailto:ak...@su...]=20
> Subject: Re: [Lse-tech] RE: 10/1 LSE call topics: Cpusets and=20
> real-time app needs.
>=20
> >=20
> > The following is a partial list of things I'm working on,=20
> and I welcome
> > any input or involvement on these or related topics.
> >=20
> > 1)	Latency degradation of simple real time POSIX API test cases as
> > a system work loads scale.
>=20
> If you release the simple test cases and post pointers to them to
> linux-kernel you could actually get help in fixing them.
>=20
> I suspect the work to do that would quickly pay off ;-)

This IS the primary goal of the test case / work load development.
Given the feed back from the telco ISV's we have a good probability of
exposing some issues.  Our implementation plan for these has having
something to share by the end of the year, sooner if there is interest
in potential participants in test case implementation.

( big hint ;)

This particular body of code is soft RT POSIX latency centric.

>=20
> > 2)	Considering the development of tools to help locate kernel
> > bottlenecks.
>=20
> There are plenty of tools around for various purposes. Lots=20
> of profilers
> like oprofile.
>=20
> IIRC the reiserfs people have an sleep-o-meter patch that may=20
> be useful
> to find problems that are caused by ineffective sleeping.
>=20

That sleep-o-meter sounds interesting.  My hunch is that most of the
performance degradations are due to semaphore locks and critical
application execution getting blocked by some lock holder.  Most profile
tools don't help much with bottlenecks of processes waiting on a lock.

--mgross