From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Hellstrom Subject: Re: [RFC] drm/ttm: add pool wc/uc page allocator Date: Wed, 03 Mar 2010 15:19:43 +0100 Message-ID: <4B8E6FFF.3000708@shipmail.org> References: <1267392603-8915-1-git-send-email-suokkos@gmail.com> <548cdfc21003011432o3c6103dbj3e9d29d8f42609c3@mail.gmail.com> <1267527383.5157.10892.camel@thor.local> <4B8CFB1B.1020806@shipmail.org> <548cdfc21003030413h9594bb1hb543d998844fdd1e@mail.gmail.com> <4B8E62CB.5060407@shipmail.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.sourceforge.net To: Luca Barbieri Cc: Jerome Glisse , =?ISO-8859-1?Q?Michel_D=E4nzer?= , dri-devel@lists.sourceforge.net List-Id: dri-devel@lists.freedesktop.org Luca Barbieri wrote: >> ^^^ Luca, I've never seen this show up high on a profile (yet). Do you see >> that with Nouveau? I used to have an rb-tree implementation of drm_mm_xxx >> lying around, but I didn't use it because I didn't have a case where it >> showed up? >> > > Yes, before I did userspace allocation, in doom3 profiles, > get_unmapped_area and function called by it (all coming from sys_mmap) > consumed around 10% of the time. > > Note that this is not DRM-specific code, but rather the generic Linux > code for finding free virtual address space, which walks over all the > vmas in the process and, in the default x86 variant, does an rb-tree > lookup for each vma! > Ah, OK. I thought this was the drm linear search for device address space for each bo. > It could be fixed by either in the kernel with better data structures > and algorithms or in userspace by using MAP_FIXED. > However, this will still leave significant kernel overhead (e.g. just > drm_mm_search_free_in_range takes 1%). > /Thomas ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev --