Yep. I think that if we could use the same conventions in both places, it
would be nice.
Not a requirement, just a nice-to-have... I realize that the styles don't
currently match.
Mike
Rafael Vanoni wrote:
Michael Pogue wrote:
I was thinking mostly in terms of matching the existing n
er product=="solaris", and many of the 234
are
community-oriented projects).
Mike
Rafael Vanoni wrote:
Michael Pogue wrote:
Better might be: utility/latencytop
Mike
I think performance/latencytop might be a better one because the main
categories in defect.os.org are community/project o
Better might be: utility/latencytop
Mike
Krishnendu Sadhukhan wrote:
Since latencytop has been made available to the OpenSolaris community, we now
need a new bug category/subcategory for filing bugs against this tool. Since
this tool is used to find out system and application latencies, in or
+1 from me as well.
Mike
Jonathan Chew wrote:
> Eric Saxe wrote:
>> johan...@sun.com wrote:
>>
>>> I'm going to begin this process by voting in favor of renewing akolb,
>>> barts, esaxe, johansen, jjc, mpogue, and dp. If andrei or rmc are still
>>> interested in participating, I would support
+1 from me. Great idea.
Mike
Jonathan Chew wrote:
> I would like to get sponsorship from the OpenSolaris performance
> community to host a CMT project which will focus on observability,
> performance enhancements, and potentially more in OpenSolaris for Chip
> Multi-Threaded (CMT) processors
Yes, this one, too! +1
Mike
Jonathan Chew wrote:
> I would like to get sponsorship from the OpenSolaris performance
> community to host a NUMA project.
>
> The "Memory Placement Optimization" feature in Solaris has been around
> since Solaris 9 and has had web pages in the OpenSolaris perform
Yipes! The 32-vs-64-bit thing bites us a lot when people are doing
Linux-to-Solaris comparisons.
If you just say "gcc" on Linux on a 64-bit CPU, you get a 64-bit binary. On
Solaris,
the default is 32-bit (even on a 64-bit CPU), unless you use -m64. This was
done for
maximum portability (32-b
IMHO, it depends a lot on exactly what the app is doing.
I can think of a couple of possible reasons for the differences here:
- the time taken by the memory allocator itself (depends on how many, and what
sizes you're
asking for), and
- the exact placement of the memory can also (greatly) af
+1 from me, too...
Alexander Kolbasov wrote:
>> Great suggestions. Richard is already a core contributer in the community.
>> I would like to nominate Jim Mauro and Adrian Cockcroft for core
>> contributer grants.
>
> Big +1!!
>
>
> ___
> perf-discus
Yes! +1
Mike
Alexander Kolbasov wrote:
>> I'd like to nominate Sherry Moore for a core contributer grant in our
>> community.
>
> +1
>
> - akolb
>
>
> ___
> perf-discuss mailing list
> perf-discuss@opensolaris.org
__
Yes, another +1...
Mike
Bill Holler wrote:
> I'd like to nominate Robert Kasten for a contributor grant in our community.
>
> Robert has made (and continues to make) tremendous contributions to the
> perf community sponsored OpenSolaris Intel-platform Project.
> He provides code drops for per
+1 from me...
Alexander Kolbasov wrote:
>> I'd like to nominate Ashok Raj for a contributor grant in our community.
>
> +1
>
> - akolb
>
> ___
> perf-discuss mailing list
> perf-discuss@opensolaris.org
___
p
+1
Alexander Kolbasov wrote:
>> I'd like to nominate Aubrey Li for a contributer grant in our community.
>
> +1
>
> - akolb
>
> ___
> perf-discuss mailing list
> perf-discuss@opensolaris.org
___
perf-discuss
A side comment about the Stream benchmark: it is HIGHLY sensitive to
placement and length of the arrays in memory. Different compilers can
place the arrays differently in memory, which can result in very
different results. This can happen with different compilers, different
switches on the s
Yuk. You're right. I will talk to the Studio11 folks, and see if we
can get this clause removed.
I've seen this clause before in other licenses (it did get removed when
we asked).
Let's see what we can do!
Mike
Eric M. Mantion wrote:
I hate to rain on the parade, but isn't this whole thr
I believe a bug has already been filed on this: 6415113.
As far as details so far, I think we've learned (by asking Colm) that this is a
micro-benchmark for Apache -- it basically tests how fast Apache can serve up a
single static 100 byte file containing all zeros.
Current status: we're set
See also Apple's Spotlight, which is similar to Linux's Beagle. I believe that
Windows-Next will also have this capability. So, yes, I think this should be a
primary use case for this new API.
Mike
John Levon wrote:
On Wed, May 03, 2006 at 07:31:08PM -0700, Prakash Sangappa wrote:
If you
Andrei,
That's percentage of what, exactly? For example, if one CPU is in a
low power state (I know Solaris 10 doesn't do this now, but I'm thinking
ahead to the future), then does the X% CPU cap represent the fraction
relative to a all-CPUs-full-on 100%, or to the reduced-power-condition's
Two comments:
1) Since we're open source now, I would encourage everybody to post
their proposed changes to libmicro here for review and discussion. Also
remember that everybody who contributes such changes needs to have a
Contributor Agreement signed and faxed in (Sun employees are essential
Bob,
You're right. It seems to work OK with 'cc', 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.
Mike
Bob Palowoda wrote:
I don't know if it related to my envionment but when I compile the tests
with gc
20 matches
Mail list logo
