Date: Sun, 15 Apr 2012 20:53:02 +0200 From: Alexander Leidinger <Alexander@Leidinger.net> To: Alexander Best <arundel@freebsd.org> Cc: freebsd-emulation@freebsd.org Subject: Re: [PATCH] pipe2 for Linuxulator Message-ID: <20120415205302.00005855@unknown> In-Reply-To: <20120415181613.GA52958@freebsd.org> References: <20120415000246.0000736b@unknown> <20120415000216.GA53624@freebsd.org> <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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 15 Apr 2012 18:16:13 +0000 Alexander Best <arundel@freebsd.org> 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...). > 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. Bye, Alexander. -- http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120415205302.00005855>