On Mon 30 Nov 2009 at 01:36PM, Dan Price wrote:
> On Mon 30 Nov 2009 at 04:39AM, Mikael Kjerrman wrote:
> > I appreciate it, but unfortunately I can not connect to the repository from
> > work.
> >
> > thanks
> >
> > //Mike
>
> Mikael, I&#x
On Mon 30 Nov 2009 at 04:39AM, Mikael Kjerrman wrote:
> I appreciate it, but unfortunately I can not connect to the repository from
> work.
>
> thanks
>
> //Mike
Mikael, I'll see if I can fix it.
-dp
--
Daniel Price, Solaris Kernel Engineeringhttp://blogs.sun.com/dp
_
dtrace providers have stability attributes. (I
> believe this was originally suggested by Dan Price, though I'd have to
> look -- the point is I don't want to falsely take credit for the
> idea).
Jason,
This idea has been in the wind for a long time. I ought not get credit
for
On Fri 13 Feb 2009 at 04:28PM, Jason King wrote:
> getting it working), me and Steven Stallion were told it will _never_
> be putback into any Opensolaris consolidation, even if it were perfect
> in every possible way (not that I'd claim it would ever approach that)
> solely because of one group wi
On Fri 13 Feb 2009 at 03:32PM, Jason King wrote:
>
> I would like the think that, all the (summarized) 'never use any
> kstats -- those are private' emails I'm getting off list, as well as
> past reactions I've seen seem to suggest otherwise (not that I'm
> really going to let it stop things -- I'
On Thu 12 Feb 2009 at 09:12AM, Peter Tribble wrote:
> On Thu, Feb 12, 2009 at 3:05 AM, Bob Friesenhahn
> wrote:
> > On Thu, 12 Feb 2009, Martin Bochnig wrote:
> >>
> >> So, one day later they had grown further, but here comes the absolute
> >> HAMMER: One top process was at 1340MB!!!
> >
> > Your
On Fri 05 Oct 2007 at 03:04PM, Spencer Shepler wrote:
>
> On Oct 5, 2007, at 2:55 PM, Ben Rockwood wrote:
>
> > Spencer Shepler wrote:
> >>
> >> On Oct 5, 2007, at 2:14 PM, Ben Rockwood wrote:
> >>
> >>> Looks like some files are missing from the distribution. Is this
> >>> what was meant by:
On Tue 19 Jun 2007 at 09:37PM, Luke Schwab wrote:
> Hi,
>
> I have recently been running performance tests with zones on several
> Sun servers. (280's and 880's), 2 CPU and 8CPUs respectively.
>
> On my 280 servers (2CPU machines), I installed and booted 3 zones and
> I get poor performance on ac
On Mon 09 Apr 2007 at 11:01PM, adrian cockcroft wrote:
> I don't have a contributor agreement on file, but I think its overkill
> for this purpose, I've copied some diffs below, which gets it to run
> up to the point where it runs out of processes on OSX. I just wanted
> to see how libmicro worked
On Sun 08 Apr 2007 at 10:46AM, adrian cockcroft wrote:
> Thanks Dan, this is a generally useful test suite.
>
> I tried to get it working on my Mac OSX/G4 laptop, and found some
> portability issues. I have most of it working apart from the tests
> that involve fork. I have modified the makefile a
Thanks to some help from Liane, today I got the libMicro 0.3.0 source
checked into a Mercurial repository on OpenSolaris.org. This should
hopefully enable easier and moer broadly based contributions to this
very fine performance tool.
I've also moved the relevant content from the performance com
On Thu 22 Mar 2007 at 08:44AM, [EMAIL PROTECTED] wrote:
> >If you run your two variants under truss -c, you may see that under CC
> >this seems to generate an excess of lseek's. I'm not sure why:
>
> This is the problem with the default C++ library, I believe.
>
You're right. That works great.
On Wed 21 Mar 2007 at 10:24PM, allen mathias wrote:
> Apologies for not posting this earlier. This is the source code.
>
> int main()
> {
> string line;
> ofstream fsmo;
> fsmo.open("temp.temp.ae");
>
> ifstream fsm;
> fsm.open("temp.ae");
> getline
On Wed 21 Mar 2007 at 09:37PM, allen mathias wrote:
> Also I notice that if instead of using fstreams I use cin and 'cat'
> the file into my test program the time values are in favor of the
> Solaris system.
>
> ufs logging is set on all disks.
>
> Can anyone shed some light on this.
Allen, I t
On Wed 18 Oct 2006 at 08:01PM, Jason King wrote:
> We have a third party library (which we do not have the source for),
> that calls getpid() everytime it logs something. Unfortunately, in
> the application where the library is being used, this results in over
> 4000 getpid calls/sec (accounting f
On Tue 03 Oct 2006 at 04:01PM, Eric Saxe wrote:
> >Timing measurements were made with snoop.
I just saw a mail from Jim Carlson over on dtrace-discuss about how snoop's
timestamps aren't very accurate due to its use of bufmod...
http://www.opensolaris.org/jive/thread.jspa?messageID=61494
I'm
On Wed 22 Mar 2006 at 07:32PM, Rama Krishna wrote:
> In our solaris system atomic_cas( ) is not available in user
> space,to make it available we require to download some of the
> patches. So we are making use of our own atomic primitive. Base on
> your guidance we are trying to modify our
On Fri 27 Jan 2006 at 05:22PM, Roman wrote:
> I've given up, this benchmark needs more thought and testing. Some
> tests just get stuck in infinite loops
>
> Running: mallocT2_1k
>
> 10 hours later, it's still running... and that is on 440MHz Sparc
> machine, running Solaris 10.
>
> Rest
On Tue 24 Jan 2006 at 09:33AM, Bart Smaalders wrote:
> >On NetBSD sparc64, compiled with gcc and -O2 optimisations, the benchmark
> >goes into infinite loop, because of the way automatic variables are
> >handled after calling longjmp(), i.e. their value is indeterminate, which
> >is affected by
On Thu 18 Aug 2005 at 09:27PM, Robert W. Fuller wrote:
> Uhh dare I ask What is multiview? Does someone have a link?
>
> Dan Price wrote:
Sorry. It's part of libMicro.
http://www.opensolaris.org/os/community/performance/libmicro/
It's a scary awk script which out
(Whenever I hear "multiview" I can't help but think of a pinball game I
used to play which had a voice which would, at the appropriate moment,
yell in a hacky transylvanian accent: "multiball -- MultiBall --
MULTIBALL -- HAHAHAHA!")
Anyway, here are some diffs to fix a number of html problems; th
On Thu 18 Aug 2005 at 04:33AM, Alexey Roytman wrote:
> The libMicro on the following Solaris versions (uname -a):
> SunOS shemesh 5.11 snv_15 i86pc i386 i86pc
> SunOS maadim 5.10 Generic i86pc i386 i86pc
> When running "./bench > out.txt", the tests longjmp and siglongjmp eat CPU
> but does no
[resend, fixing attachment]
Ok. Attached is a preliminary DEBUG vs. non-DEBUG comparison; I
eliminated the one test which was very obviously misfiring. It could be
that there are others which are also misbehaving.
For those not acquainted with what I'm measuring: there are two ways to
build th
On Thu 18 Aug 2005 at 01:54AM, Phil Harman wrote:
> Dan,
>
> This is related to the undersized batch issue I mentioned in an earlier
> thread. From your data we can see that the batch (sample) size is 1.
> This is broken. It means that alternate batches will use PROT_NONE and
> PROT_READ | PROT
I'm seeing the following libmicro computation regarding mprotect, which
looks fishy to me. Interesting to note that libmicro eventually
discards all of the results > 100 usecs, leading it to conclude that
this system call is taking 1usec per call. Plus, there's a very odd
distribution of times.
On Thu 11 Aug 2005 at 01:52PM, Devon H. O'Dell wrote:
> b) There's actually currently no limit on the amount of byte-range
> locks you can hold.
(Except that the problem we're discussing here is libMicro running on
Darwin).
:)
-dp
--
Daniel Price - Solaris Kernel Engineering - [EMAIL
On Thu 11 Aug 2005 at 11:56AM, Eric Saxe wrote:
> > This might sound dumb, but are we sure that processes are the resource
> > which is temporarily unavailable?
>
> I think what you are saying, Dan, is that "this might be so obvious that
> it has escaped you", and you very well might be right. :)
On Thu 11 Aug 2005 at 11:22AM, Eric C. Saxe wrote:
> Ben Cooper wrote:
>
> > Interestingly when I ran the cascade_flock 200 test
> > manually I got
> > the resource temporarily unavailable fork error
> > straight away, so I
> > don't think it's libMicro not waiting for the
> > processes of pr
On Tue 09 Aug 2005 at 04:36PM, Alexander Kolbasov wrote:
>
> - Adding support for ptys as a loopback pipe mechanism.
Can you expand this a little? I'd like to understand better.
Under what conditions is pty performance interesting?
To put it another way, doesn't a pty usually have a (slow) hum
29 matches
Mail list logo
