From owner-cvs-all@FreeBSD.ORG Sat Mar 5 15:08:30 2005 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 665CF16A4CE; Sat, 5 Mar 2005 15:08:30 +0000 (GMT) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id F29DB43D2F; Sat, 5 Mar 2005 15:08:29 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) j25F8SQl007614; Sat, 5 Mar 2005 10:08:28 -0500 (EST) Date: Sat, 5 Mar 2005 10:08:28 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Alexey Dokuchaev In-Reply-To: <20050305101211.GA59471@FreeBSD.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) cc: cvs-src@freebsd.org cc: src-committers@freebsd.org cc: David Xu cc: cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/sys proc.h umtx.h src/sys/kernkern_thread.c kern_umtx.c X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Daniel Eischen List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Mar 2005 15:08:30 -0000 On Sat, 5 Mar 2005, Alexey Dokuchaev wrote: > On Sat, Mar 05, 2005 at 09:15:03AM +0000, David Xu wrote: > > davidxu 2005-03-05 09:15:03 UTC > > > > FreeBSD src repository > > > > Modified files: > > sys/sys proc.h umtx.h > > sys/kern kern_thread.c kern_umtx.c > > Log: > > Allocate umtx_q from heap instead of stack, this avoids > > page fault panic in kernel under heavy swapping. > > So.. Slow malloc/free path at last. As a side note, could someone (not > necessarily David) comment on my impression that, for example, recently > reported not-so-optimal performance of our threading model(s) is largely due > to heavy use of malloc/free, as opposed to other operating systems out > there? Am I right thinking that this is main bottleneck? If malloc'ing is > so costly, why we're taking this path? Can kernel malloc() be optimized? There is room for improvement in the kernel upcall path. I got about a 7% improvement in some tests by caching upcall threads in the kernel rather than using a zone and always alocating them when needed. http://people.freebsd.org/~deischen/kse/sys.diffs I don't know whether the patches are totally correct. There is also room for improvement in libpthread. It was first designed for correctness, not speed. I'm working on some changes to improve mutex performance. -- DE