From owner-freebsd-hackers Sat Feb 15 23:53:46 2003 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6B3EA37B401 for ; Sat, 15 Feb 2003 23:53:45 -0800 (PST) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2288443F3F for ; Sat, 15 Feb 2003 23:53:45 -0800 (PST) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id EF523AE1C6; Sat, 15 Feb 2003 23:53:42 -0800 (PST) Date: Sat, 15 Feb 2003 23:53:42 -0800 From: Alfred Perlstein To: hackers@freebsd.org Subject: rfc, optimizing select/poll. Message-ID: <20030216075342.GD93252@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG please include me on cc' as I'm not subscribed to this list. I'm thinking about doing some more work on select/poll for freebsd. The gist of my changes would be two modifications. 1) when select has to allocate space via malloc, cache it in the proc struct to avoid dipping into malloc on future calls. 2) get rid of select collisions. now that we have the tracking of the selinfo structs, we can actually allocate then ahead of time and hang them off of the selinfo in the objects, this would have some memory overhead, but get rid of the collision problem. So, what I'm asking is... Can anyone state ahead of time why they would object to this? (please reply publically) Who will test it? (privately plz) Thanks! -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message