input thread [was Re: [PATCH v2] input: constify valuators passed in by input drivers.]

[Aaron Plattner]

On Fri, Aug 13, 2010 at 08:09:24AM -0700, Adam Jackson wrote:
> On Fri, 2010-08-13 at 08:51 -0300, Fernando Carrijo wrote:
> > And to be honest, it seems to me that the precautions taken by the
> > smart scheduler to penalize hungry clients isn't enough in certain
> > circumstances. Firefox abusive usage of XPutImage comes to my mind,
> > even though I'm completely unaware of the reasons that make the cost
> > of this operation to be so expensive.
> 
> PutImage sucks because it's at least two copies through the unix socket,
> one from the client down to the kernel and one back up from the kernel
> to the server.  Once you've done that you still have to get the data
> into the driver's storage, which is either a memcpy into host memory
> somewhere or DMA up to the video card.  However, the way it's
> implemented now, that's all synchronous; even if you DMA it up to VRAM,
> you have to block the server until the DMA completes.
> 
> ShmPutImage is a bit better in that it elides the socket copies, but
> that last memcpy or DMA still has to fire, and it still completes
> synchronously; the server won't advance to the next request until it's
> done.

I know it's nitpicking, but this is false at least for our driver.
{Shm,}PutImage is pipelined and you can have a potentially large number of
them in flight at a time.

> And of course {Shm,}GetImage have all the same problems.

GetImage obviously does have to wait until the DMA is complete, so it's
worse than PutImage.