Running with the brakes on ...
Owen Taylor
otaylor at redhat.com
Mon Dec 4 22:56:17 UTC 2006
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 at 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
finish.
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
More information about the fedora-devel-list
mailing list