[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Running with the brakes on ...

On Mon, 2006-12-04 at 20:11 -0500, Adam Jackson wrote:
> On Mon, 2006-12-04 at 14:47 -0900, Jeff Spaleta wrote:
> > On 12/4/06, Adam Jackson <ajackson redhat com> wrote:
> > > So you've found that some use profile makes X use all the CPU.  Now you
> > > need to find out _what_ in X is taking all the time.  You need to either
> > > use a tool like oprofile or sysprof to extract that information, or you
> > > need to instrument the X server to report on what requests and clients
> > > are using most of its time.  The latter requires code changes to a
> > > project that many people find intimidating and/or unpleasant to work
> > > with, which is why I suggested using oprofile in the first place.
> > 
> > is xrestop at all useful in this situation?
> Not at the moment.  xrestop right now is only useful for showing you
> client memory allocations (see /usr/include/X11/extensions/XRes*.h for
> the gory details).  It would be pretty straightforward to hook up some
> basic per-client accounting in the scheduler, although it's slightly
> tricky to do that while not blowing away your dispatch performance,
> gettimeofday() is equivalent to about 10 (no-op) client requests.
> There's different metrics you want to measure there - number of
> requests, number of scheduler punishes, number of sleeps, total request
> time - and it's not immediately clear to me which ones would be worth
> doing and which would just be overhead.  Would definitely be a pleasant
> thing to have though.

What someone might want to think about is whether the X server can
"leave about" the information about what client is working for
that is accessible to sysprof and oprofile when they are taking a
stack trace?

Now there are some limitations there:

 - If the server is bottlenecked by the accelerator (acceleration code
   is better than than the accelerator) then the X server is going 
   to spend most of its time waiting for some previous request to

   Luckily that's seldom the case when X is a performance problem...

 - Even if you can associate the X call with the caller, it's much
   harder to associate it with a particular stack trace in the caller
   because of the asynchronous nature of X ... that stack trace
   is a distant memory.
But it still could be useful.
						- Owen

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]