Date: Sun, 15 Apr 2012 19:04:08 +0000 From: Alexander Best <arundel@freebsd.org> To: Alexander Leidinger <Alexander@Leidinger.net> Cc: freebsd-emulation@freebsd.org Subject: Re: [PATCH] pipe2 for Linuxulator Message-ID: <20120415190408.GA61246@freebsd.org> In-Reply-To: <20120415205302.00005855@unknown> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun Apr 15 12, Alexander Leidinger wrote: > 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...). 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120415190408.GA61246>