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@xxxxxxxxxx> 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 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
