Martin wrote:
I'm using Solaris 9 (SPARC) after installing sun studio 10.
This message posted from opensolaris.org
___
perf-discuss mailing list
perf-discuss@opensolaris.org
Ah, that explains it. I added a test for one of the atomic
functions, but th
I'm using Solaris 9 (SPARC) after installing sun studio 10.
This message posted from opensolaris.org
___
perf-discuss mailing list
perf-discuss@opensolaris.org
On Thu, Aug 11, 2005 at 01:55:40PM -0700, Dan Price wrote:
> 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).
>
> 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. :)
-Eric
Eric Saxe
Solaris Kernel Development
510.550.4866
Phil Harman wrote:
Bob Palowoda wrote:
There is probably nothing wrong with connection it just toke
123sec on a 3.2ghz machine. I just didn't wait long enough.
Phew! 123sec is a long time. Maybe your machine was busy doing other
stuff in the background? Before 0.3.0 we used to run eac
On Thu, Aug 11, 2005 at 01:28:08PM -0700, Dan Price wrote:
> 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 obvio
Bob,
I'm a little behind in getting to this, but I will. Thanks for all the data.
Please also watch for a post on TCP cases in general.
Cheers,
Phil
Bob Palowoda wrote:
Phil Harman wrote:
Bob Palowoda wrote:
There is probably nothing wrong with connection it just toke
123sec on a 3.2gh
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
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 previous
> tests to run. When I tried putting the kern.maxproc
> an
Bob Palowoda wrote:
There is probably nothing wrong with connection it just toke
123sec on a 3.2ghz machine. I just didn't wait long enough.
Phew! 123sec is a long time. Maybe your machine was busy doing other
stuff in the background? Before 0.3.0 we used to run each test case for
5 sec
Eric C. Saxe wrote:
Dan Price points out that this could be a case where some "volatility" is
necessary.
I made the loop counter "i" volatile, and the problem went away.
Great work. Thanks guys! It's not the first time we've had to fight the
optimiser. Actually, running libMicro with and w
> In the case of longjmp.c siglongjmp.c, these diffs
> will fix things:
> [EMAIL PROTECTED] sccs diffs longjmp.c siglongjmp.c
>
> --- longjmp.c ---
> 29c29
> < int i = 0;
> ---
> > volatile inti = 0;
>
> --- siglongjmp.c ---
> 38c38
> <
Dan Price points out that this could be a case where some "volatility" is
necessary.
I made the loop counter "i" volatile, and the problem went away.
Looking at the disassembly and comparing for the two cases (siglongjmp)
(volatile)
benchmark+0x1b: 8d 45 fc leal -0x4(%ebp),%ea
> You're right. It seems to work OK with 'cc', but
> but these 3 benchmarks
> also fail with gcc 3.4.3 (which is the version that
> is part of Solaris10
> right now). I'm on Nevada build 14.
This seems to be related to the gcc optimizer. I added
a "printf()" to the "if" loop in siglongjmp.c:be
16 matches
Mail list logo
