linux-kernel - Re: files/process scaling problem? (was: [PATCH] Export shmem_file_setup and shmem

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1217896442.24714.142.camel@koto.keithp.com>
Date:	Mon, 04 Aug 2008 17:34:02 -0700
From:	Keith Packard <keithp@...thp.com>
To:	Ingo Oeser <ioe-lkml@...eria.de>
Cc:	keithp@...thp.com, Alan Cox <alan@...rguk.ukuu.org.uk>,
	Arjan van de Ven <arjan@...radead.org>,
	John Stoffel <john@...ffel.org>,
	Christoph Hellwig <hch@...radead.org>,
	Eric Anholt <eric@...olt.net>, linux-kernel@...r.kernel.org
Subject: Re: files/process scaling problem? (was: [PATCH] Export
	shmem_file_setup and shmem_getpage for DRM-GEM)

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@...el.com

Download attachment "signature.asc" of type "application/pgp-signature" (190 bytes)