[PATCH] pipe2 for Linuxulator

[Alexander Best]

On Sun Apr 15 12, Alexander Leidinger wrote:
> On Sun, 15 Apr 2012 18:16:13 +0000 Alexander Best <arundel at 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