From owner-freebsd-emulation@FreeBSD.ORG Sun Apr 15 19:04:08 2012 Return-Path: Delivered-To: freebsd-emulation@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 980F21065673; Sun, 15 Apr 2012 19:04:08 +0000 (UTC) Date: Sun, 15 Apr 2012 19:04:08 +0000 From: Alexander Best To: Alexander Leidinger Message-ID: <20120415190408.GA61246@freebsd.org> References: <20120415101157.GA67049@freebsd.org> <20120415112308.GA77985@freebsd.org> <20120415134444.000005cc@unknown> <20120415115112.GA83717@freebsd.org> <20120415143441.00000948@unknown> <20120415130306.GA95208@freebsd.org> <20120415163059.0000715d@unknown> <20120415144155.GA15993@freebsd.org> <20120415181613.GA52958@freebsd.org> <20120415205302.00005855@unknown> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120415205302.00005855@unknown> Cc: freebsd-emulation@freebsd.org Subject: Re: [PATCH] pipe2 for Linuxulator X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Apr 2012 19:04:08 -0000 On Sun Apr 15 12, Alexander Leidinger wrote: > On Sun, 15 Apr 2012 18:16:13 +0000 Alexander Best > wrote: > > > On Sun Apr 15 12, Alexander Best wrote: > > > here are the results for a single flash instance: > > > > otaku% sudo time ./check_internal_locks.d > > > Number of locks per type: > > futex_mtx 4585 > > > > 18,48 real 0,10 user 0,36 sys > > > > and here for two flash tabs: > > > Number of locks per type: > > futex_mtx 29364 > > > > 19,41 real 0,09 user 0,32 sys > > > > ...and for three flash tabs: > > > > otaku% sudo time ./check_internal_locks.d > > > Number of locks per type: > > emul_shared_wlock 14 > > emul_lock 20 > > futex_mtx 45571 > > > > 22,46 real 0,11 user 0,35 sys > > A lot more calls to the futex-lock than you would assume. It's not > linear to the amount of flash instances. Maybe worth investigating > (optimization opportunity?). > > > > > i've tuned the script to have the maximum buffer size of 256 megabyte > > via > > > > #pragma D option dynvarsize=256m > > #pragma D option specsize=256m > > > > ...still the buffers seem to be too small. > > The scripts do a lot. The serve more as examples of what you can do, > than to really serve as a debugging aid in all situations. They give a > hint if there's something to investigate or not. In your case it is > maybe not a bad idea to remove all emul-lock parts and only keep the > futex-stuff (or a part of it...). thanks for the hint. i'll try to comment out any non-futex related stuff. > > > also...even after installing a fresh kernel and world with dtrace > > enabled, the "check_error.d" and "trace_futexes.d" fail and sometimes > > even render the flash instance unusable. > > I assume with unusable you mean not fast enough. Well... buy a faster > CPU. No, just kidding. Depending on what a D script does and how many > probes are enabled in the D script, it is not unexpected that the > system slows down. As told above, the scripts show what is possible. > For real debugging you may want to use stripped down versions. no actually. what i meant by "unusable" is that the d-scripts themself crash the flash instances. > > Bye, > Alexander. > > -- > http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 > http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137