On Sat, 2004-11-06 at 18:11 +0000, Keith Whitwell wrote: > > My questions would be: > > > > - Is this interesting to anybody but me? It's been quite useful to me > > so far in just the couple of hours I've had it working... > > It's definitely interesting. Have you been using it to tune an application, > or from the point of view of tuning driver behaviour?
Well, some of both. I was seeing some bad performance on the app that
I was blaming on the driver... I thought I was running out of texture
ram and the LRU swap algorithm was causing problems. But once I had
texturetop up and running, it was clear that I was just doing something
stupid in my app :-)
> > - Does this duplicate something else that is out there already?
>
> Not to my knowledge.
Cool.
> > - What's the chance of getting this integrated into the main sources?
>
> I think pretty good. Mesa wraps some things that are called directly by the
> patch, I'm not sure what the gotchas with libraries creating threads without
> the applications knowledge are, but if it's only done in response to an
> environment flag & maybe a compile option, I can't see that being a problem.
One of the reasons I used a separate thread was that it is pretty much
invisible to the application - requiring application main loop
integration or even forking off a child process would be a lot more
intrusive. (Forking off child processes gets you in trouble with
SIGCHILD)
Given a POSIX compliant thread implementation (like NPTL), the main
possible area of difficulty I can think of is signal delivery - POSIX
specifies that signals are delivered randomly to a thread not blocking
that signal, so if the app is, say, counting on a select() call in their
main thread being woken up when a signal comes in, that might not
happen.
Calling pthread_sigmask() with sigfillset() when the thread starts would
help that.
Another occurs to me in this area is that the patch probably should set
CLOEXEC on its file descriptors.
But these are small details, and as you say, if its something that has
to turned explicitly, it's not a big deal if it causes a particular
app to misbehave.
> It'd be good to let people play around with it a little first, which for me
> means early in the week, most likely.
Sounds good,
Owen
signature.asc
Description: This is a digitally signed message part
