Messages in this thread | | | Subject | Re: files/process scaling problem? (was: [PATCH] Export shmem_file_setup and shmem_getpage for DRM-GEM) | From | Keith Packard <> | Date | Mon, 04 Aug 2008 17:34:02 -0700 |
| |
On Mon, 2008-08-04 at 23:46 +0200, Ingo Oeser wrote:
> Ok, how many need support for GEM? How many of them would change their > event loop, if they can get better performance?
GEM will underlie the OpenGL implementation that applications use; we aren't planning on writing two OpenGL implementations to work around some file descriptor issues. And, even if we want to use fds for every GEM object, we have a fairly simple way of moving them out of the way of select -- dup2. Of course, it would be nice to have some way to get the kernel to help allocate an unused fd 'up high', but
> Really, the sleeping part of of event loops is usually hidden > in some libraries and the applications have a big switch statement > somewhere to dispatch the reasons for wakeup.
That's not historically true in desktop applications. Yes, most modern open source applications are sensible and use a library-based event loop, but we can't control what applications people use.
> That is never required as long as only performance suffers, > not functionality.
Alas, GEM offers a huge increase in functionality; performance is really just a modest side benefit.
In reality, as I want to avoid problems caused by ulimit, I suspect I'd end up treating most of these objects as just a bag of pages and close the related fd after passing them to the driver, effectively turning the whole exercise into a mechanism for passing the struct file from shmem to GEM through user mode instead of directly across the kernel API. I'm not sure this is a win.
-- keith.packard@intel.com [unhandled content-type:application/pgp-signature] | |