[PATCH] pipe2 for Linuxulator

[Alexander Leidinger]

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...).

> 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