XOpenDisplay takes a long time to return

[Robert Morell]

On Fri, Jun 28, 2013 at 12:09:10PM -0700, Divick Kishore wrote:
> Hi,
>     I have installed nvidia OpenGL drivers on amazon gpu cluster
> instance which has two Tesla M2050 GPUs and I see a weird behavior
> when I run any two apps in quick succession.
> 
> I am running the server in a headless mode with xorg.conf generated
> using the following options:
> 
> sudo nvidia-xconfig -a --no-xinerama --no-dynamic-twinview
> --use-display-device=None --virtual=1280x1024
> 
> which maps two screens each of them to two devices.
> 
> Finally I run X Server using:
> 
> sudo /usr/bin/X :0
> 
> and then I run any application on any one of the GPUs using:
> 
> #Runs it on first GPU
> export DISPLAY=:0.0 glxgears
> 
> #Runs it on second GPU
> export DISPLAY=:0.1 glxgears
> 
> I noticed that sometimes it takes a very very long time (~couple of
> seconds to a minute) before a call to XOpenDisplay succeeds. It is not
> clear if the issue is with X server or with nvidia drivers or possibly
> with my xorg settings.
> 
> I notice that when an application exits the output is similar to the
> following output (see below below this paragraph) on the terminal
> where I started the X. Only when this is dumped when the previous
> application exits / closes the display, the XOpenDisplay succeeds. So
> it seems that only after either the driver of X does some cleanup the
> subsequent XOpenDisplay succeeds.
> 
> 12 XSELINUXs still allocated at reset
> SCREEN: 0 objects of 344 bytes = 0 total bytes 0 private allocs
> COLORMAP: 0 objects of 8 bytes = 0 total bytes 0 private allocs
> DEVICE: 0 objects of 104 bytes = 0 total bytes 0 private allocs
> CLIENT: 0 objects of 152 bytes = 0 total bytes 0 private allocs
> WINDOW: 0 objects of 72 bytes = 0 total bytes 0 private allocs
> PIXMAP: 4 objects of 112 bytes = 448 total bytes 0 private allocs
> ...
> ...
> TOTAL: 8 objects, 320 bytes, 0 allocs
> 
> 
> Is there someone who could help?

It sounds like the application exit may be triggering a server
regeneration, although "~couple of seconds to a minute" seems a bit long
for that.

If that is the problem, you should be able to avoid it by passing the
'-noreset' argument to the X server, i.e., start X with:

sudo /usr/bin/X -noreset :0

- Robert