Date: Mon, 4 Aug 2008 09:19:30 +0100
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: Keith Packard <keithp@keithp.com>
Cc: Ingo Oeser <ioe-lkml@rameria.de>, keithp@keithp.com,
       John Stoffel <john@stoffel.org>, Christoph Hellwig <hch@infradead.org>,
       Eric Anholt <eric@anholt.net>, linux-kernel@vger.kernel.org
Subject: Re: files/process scaling problem? (was: [PATCH] Export
 shmem_file_setup and shmem_getpage for DRM-GEM)
Message-ID: <20080804091930.164f31c3@lxorguk.ukuu.org.uk>
In-Reply-To: <1217809152.23437.401.camel@koto.keithp.com>
References: <1217573919-7496-1-git-send-email-eric@anholt.net>
	<18581.43362.460694.60862@stoffel.org>
	<1217785943.23437.330.camel@koto.keithp.com>
	<200808040135.32563.ioe-lkml@rameria.de>
	<1217809152.23437.401.camel@koto.keithp.com>
Organization: Red Hat UK Cyf., Amberley Place, 107-111 Peascod Street,
 Windsor, Berkshire, SL4 1TE, Y Deyrnas Gyfunol. Cofrestrwyd yng Nghymru a
 Lloegr o'r rhif cofrestru 3798903
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 764
Lines: 14

> The other issue is that several important applications (including the X
> server) use select instead of poll, and they have a small maximum number
> of fds that they support. It seems like this could be worked around by
> dup2'ing the shmem fds up a ways.

That would work yes. Switching to poll() would probably be even smarter,
or if you have a large number of fds being scanned take a look at epoll
which is likely to be far more efficient but wouldn't be available on so
many systems - poll is at least standard.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/