Re: files/process scaling problem? (was: [PATCH] Export shmem_file_setup and shmem_getpage for DRM-GEM)

[Keith Packard <keithp@keithp.com>]

[-- Attachment #1: Type: text/plain, Size: 1602 bytes --]

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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]