Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Tue, 15 Oct 2002 17:24:56 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Tue, 15 Oct 2002 17:24:56 -0400 Received: from zero.aec.at ([193.170.194.10]:37906 "EHLO zero.aec.at") by vger.kernel.org with ESMTP id ; Tue, 15 Oct 2002 17:24:55 -0400 To: Andrew Morton Cc: linux-kernel@vger.kernel.org, mingo@elte.hu Subject: Re: [patch] mmap-speedup-2.5.42-C3 References: <3DAC59F7.18678FA6@digeo.com> From: Andi Kleen Date: 15 Oct 2002 23:30:34 +0200 In-Reply-To: <3DAC59F7.18678FA6@digeo.com> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1358 Lines: 24 Andrew Morton writes: > Yup. We'd need to be able to perform a search based on "size of hole" > rather than virtual address. That really needs a whole new data structure > and supporting search code, I think... It also may have side effects > to do with fragmentation of the virtual address space. When you oprofile KDE startup you notice that a lot of time is spent in get_unmapped_area too. The reason is that every KDE process links with 10-20 libraries and ends up with a 40-50 entry /proc//maps. Optimizing this case would be likely useful too, although I suspect Ingo's last hit cache would already help somewhat. When you add a funky data structure please trigger it on the number of mappings at least. e.g. I bet a micro optimized (= uses prefetch) single linked list or even array will be always best for <= 10 entries, which is still not that uncommon in the non KDE world. Array would be attractive because you can trivially prefetch it, but would eat more space per mm_struct. Assuming each process has at least 5 mappings the cost should be rather small though. -Andi - 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/