Author: Bart Smaalders
Repository: /hg/libmicro/libmicro
Branch: default
Latest revision: aab5db3f83568c3f6fdce50caafa9269e746aef5
Total changesets: 1
Log message:
correct Makefile.com so that tattle works with constant strings.
Files:
update: Makefile.com
update: tattle.c
tter shell script
performance.
There are other, more generically useful performance improvements
being made in the VM system that will help this; given our limited
resources we'd rather focus on projects that have good paybacks in
multiple areas.
- Bart
--
Bart Smaalders
and improve the situation.
What does DTrace tell you about where the time is being spent?
Instead of asserting where the problem is in email, how about
doing some investigation?
- Bart
--
Bart Smaalders Solaris Kernel Performance
bart.smaald...@oracle.com http
ocess.
- Bart
--
Bart Smaalders Solaris Kernel Performance
bart.smaald...@oracle.com http://blogs.sun.com/barts
"You will contribute more with mercurial than with thunderbird."
___
perf-discuss mailing list
perf-discuss@opensolaris.org
oc_debug+0x144
libumem.so.1`umem_cache_alloc+0x19a
libumem.so.1`umem_alloc+0xcd
libumem.so.1`malloc+0x2a
libc_hwcap2.so.1`strdup+0x26
checking_strdup+0xf
retrieve_tree+0x343
main+0x5ed
_start+0x7d
...
- Bart
--
LBs? With text, stack and heap
mappings for all
threads, this result isn't terribly surprising.
Solaris cannot use the global bits for user mappings since the locations
of libraries,
etc, aren't fixed. The kernel mapping are global if the CPU supports that.
- Bart
--
Bart Smaalders
Krishna Yenduri wrote:
> Bart Smaalders wrote:
>> ...
>> Keep in mind the differences between lwps and kernel threads, esp. on
>> NUMA (MPO) platforms. Note that lgrp_choose isn't called for kernel
>> threads
>>
>
> That explains it t
erences between lwps and kernel threads, esp. on
NUMA (MPO) platforms. Note that lgrp_choose isn't called for kernel
threads
What are you trying to do?
Trying to use all the cpus in the system at minclsyspri is likely to
make interactive
use awkward, to say the least.
- Bar
ain load averages for each lgroup or fraction
thereof
that was present in each processor set.
The code is a little fussy, but we haven't come up w/ a better way of
doing this yet.
- Bart
--
Bart Smaalders Solaris Kernel Performance
[EMAIL
t; Cheers,
> - jonathan
>
> --
> Jonathan Adams, Sun Microsystems, ZFS Teamhttp://blogs.sun.com/jwadams
>
> ___
> perf-discuss mailing list
> perf-discuss@opensola
- Bill
>
This is correct. Note that the coefficients differ, however;
if each fd is ready all the time, select is more efficient since
port_get() requires a call to port_associate() for every fd.
Most large scale apps w/ thousands of fds open only has data
availabl
the debugger
> - Worked on the port of Solaris to amd64
> - Worked extensively on Solaris Dynamic Reconfiguration (DR) support
>
> Thanks,
> -Eric
>
>
>
>
> _______
> perf-discuss mailing list
> perf-discuss@opensolaris.
ed the time by a factor of ~1.5;
it's still slower by a good bit.
> 3. Which locale did you use (e.g. what is the output of $ env | egrep
> "LC_|LANG" #) ?
C locale
> 4. Could you please list the command sequence to measure the startup
> time of both Bourne shell and
onents)
>
> I think this project would be of interest to a number of OpenSolaris
> communities but I am asking the performance community for sponsorship as
> it appears to be the most relevant.
>
+1
=- Bart
--
Bart Smaalders S
only when it is enabled. So I think at most time
> copyout(getpeername) will call do_copy_fault, is right? After multiple
> tests, I start doubting on my presumption however I don't find any other
> clues. Would you like to tell me the right answer?
>
What makes you think your
project. Note that the plan is to
use a DMU object per address space or one per segment of an address space.
- Bart
--
Bart Smaalders Solaris Kernel Performance
[EMAIL PROTECTED] http://blogs.sun.com/barts
___
perf-discus
pecially within the math and HPC sciences arenas.
>
> Many thanks,
>
> Rob Giltrap
> OpenSolaris - Google Summer of Code Mentor.
Hi Rob -
Have you taken a pass at this w/ DProfile (in the latest sun studio)?
You should look for cache/tlb hots spots; this may show false sharing,
excessive conflicts, etc.
- Bart
--
Bart Smaalders Solaris Kernel Performance
[EMAIL PROTECTED] http://blogs.sun.com/barts
___
perf-discuss mailing list
perf-discuss@opensolaris.org
_
> perf-discuss mailing list
> perf-discuss@opensolaris.org
They certainly could be
- Bart
--
Bart Smaalders Solaris Kernel Performance
[EMAIL PROTECTED] http://blogs.sun.com/barts
___
perf-discuss mailing list
perf-discuss@opensolaris.org
@@ 319443
256 |@@ 60991
512 |@5972
So I'm not sure what to do.
Any clues are, as always, welcome!
Thanks,
Dan
___
perf-discuss mailing list
perf-d
s to deliver maximum system performance while
consuming no more power than is necessary to do so.
Thanks,
-Eric
___
perf-discuss mailing list
perf-discuss@opensolaris.org
I think we should def. sponsor this....
- Bart
--
Bart Smaalders
urpose workloads, and it's not clear that such machines are
interesting commercially.
- Bart
--
Bart Smaalders Solaris Kernel Performance
[EMAIL PROTECTED] http://blogs.sun.com/barts
___
perf-discuss mailing list
perf-discuss@opensolaris.org
- Bart
Thank you, Thomas
___
perf-discuss mailing list
perf-discuss@opensolaris.org
--
Bart Smaalders Solaris Kernel Performance
[EMAIL PROTECTE
efforts!
Thanks,
-Eric
___
perf-discuss mailing list
perf-discuss@opensolaris.org
An excellent idea. You are now endorsed :-).
- Bart
--
Bart Smaalders Solaris Kernel Performance
[EMAIL PROTECTED] h
g
language features. As a result, the libstlport library conforms
much more closely to the standard than libCstd does.
- Bart
--
Bart Smaalders Solaris Kernel Performance
[EMAIL PROTECTED] http://blogs.sun.com/barts
___
le provider a lot more
as it gives a less distorted view of relative time spent. How prevalent
is hat_getpfnum in your kernel profile?
- Bart
--
Bart Smaalders Solaris Kernel Performance
[EMAIL PROTECTED] http://blogs.sun.com/barts
___
esses the files.
As a mental model, I prefer to think of file events as
one-shots; passing in the stat data collected by the monitoring
app before processing a file insures that 1) no modifications are
lost and 2) as many modifications as possible are combined into
a single event.
- Bar
prakash sangappa wrote:
The 'uf_lock' is a per 'fd' lock. Therefore, the application could
possibly dup(2)
the fd, to get one for each thread. That should help avoid the uf_lock
contention.
-Prakash.
Krishna Yenduri wrote:
Bart Smaalders wrote:
Krishna Yenduri wrote:
mailing list
perf-discuss@opensolaris.org
If all the threads share the same FD, you're going to have problems
if the actual IOCTL is very fast.
Can you open the device multiple times?
- Bart
--
Bart Smaalders Solaris Kernel Performance
[EMAIL PROTECTED]
into multiple pieces after reaching it's
full size
- Bart
--
Bart Smaalders Solaris Kernel Performance
[EMAIL PROTECTED] http://blogs.sun.com/barts
___
perf-discuss mailing list
perf-discuss@opensolaris.org
e to separate threads bound
to different CPUs (either cores or sockets).
3) use of large pages
More details about the data structures, machine architecture
and CPU count would allow more targeted suggestions....
- Bart
--
Bart Smaalders Solaris Kernel Performance
[EMAIL PROTECTED]
ou're spending a lot of time in ata_wait, this is the
problem.
=- Bart
--
Bart Smaalders Solaris Kernel Performance
[EMAIL PROTECTED] http://blogs.sun.com/barts
___
perf-discuss mailing list
perf-discuss@opensolaris.org
Matty wrote:
On Wed, 24 May 2006, Bart Smaalders wrote:
Our initial plans for PowerNow support will maintain some
% of idle cpu. If your app is very latency sensitive but
spends most of it's time sleeping, you'll want to use a different
policy.
Any idea when this will be added
pu has far less effect than if my app is
running out of the L1 caches.
Our initial plans for PowerNow support will maintain some
% of idle cpu. If your app is very latency sensitive but
spends most of it's time sleeping, you'll want to use a different
policy.
- Bart
--
Bart Smaalders
_
perf-discuss mailing list
perf-discuss@opensolaris.org
That works fine w/ nawk; I've made that change in the
source base.
Thanks!
- Bart
--
Bart Smaalders Solaris Kernel Performance
[EMAIL PROTECTED] http://blog
ty issues; can an application
use this to watch the creation of files in someone else's 0700
directory?
- Bart
--
Bart Smaalders Solaris Kernel Performance
[EMAIL PROTECTED] http://blogs.sun.com/barts
___
perf-discuss mailing list
perf-discuss@opensolaris.org
Seth Goldberg wrote:
Hi,
With Justin's testing, I have a fix for this, so if anyone else is
experiencing this problem, please let me know so I can have you test the
fix as well.
Thanks,
--S
Excellent. Thanks for going after that!
- Bart
--
Bart Smaalders So
Thanks,
--S
Since this is the second time this has happened, perhaps a
blog entry or something would be useful to let folks know
how to solve it on their own if this is possible.
Why doesn't windows/linux have problems w/ this?
- Bart
--
Bart Smaalders Solaris
Justin Conover wrote:
http://www.opensolaris.org/jive/thread.jspa?messageID=11873โนก
<http://www.opensolaris.org/jive/thread.jspa?messageID=11873โนก>
This could be a winner
That's it!
Ok, now to figure out how to fix this.
I've cc'd Seth, perhaps he can chime in.
- Ba
M quite so aggressively.
What does intrstat report in terms of interrupts? We've seen some
issues with some bioses confusing edge triggered vs level triggered
interrupts.
- Bart
--
Bart Smaalders Solaris Kernel Performance
[EMAIL PROTECTED] http://blogs.s
te of 32 * 8K. You may wish to patch
core_chunk in /etc/system (or w/ mdb -kw for real time experiments)
to see if reducing the size of writes will help.
http://cvs.opensolaris.org/source/xref/on/usr/src/uts/common/os/core.c#core_chunk
DTrace is your friend here as well...
ached.
- Bart
--
Bart Smaalders Solaris Kernel Performance
[EMAIL PROTECTED] http://blogs.sun.com/barts
___
perf-discuss mailing list
perf-discuss@opensolaris.org
ore files onto
disks or NFS servers that will cope w/ a flood of IO is
a good idea. This would also help diagnose the
actual cause of the problem.
In general, we strongly encourage ISVs not to disable core
dumping as it makes finding that once every 6 month crash
very difficult indeed.
- Bar
s for plat_lgrp_init
in the source browser.
- Bart
--
Bart Smaalders Solaris Kernel Performance
[EMAIL PROTECTED] http://blogs.sun.com/barts
___
perf-discuss mailing list
perf-discuss@opensolaris.org
rf-discuss mailing list
perf-discuss@opensolaris.org
What kind of hardware are you running on?
-= Bart
--
Bart Smaalders Solaris Kernel Performance
[EMAIL PROTECTED] http://blogs.sun.com/barts
___
perf-discuss mailing
t key;
int
foo()
{
return (((struct bar *)pthread_getspecific(key))->foobar);
}
you're going to want to consider passing the thread_specific
data explicitly for peak performance.
- Bart
--
Bart Smaalders Solaris Kernel Performance
[EMAIL PROTECTED] htt
a PCI framebuffer , you can prob. get
xorg up and running on SPARC and get the XRender extension.
The old SPARC graphics group is no more, essentially.
- Bart
--
Bart Smaalders Solaris Kernel Performance
[EMAIL PROTECTED] http://blogs.sun.com/
ormance
will be more important. If not, aggregate throughput will be more
interesting...
And don't forget:
"The longer a industry standard benchmark has existed, the less
likely that it has useful or meaningful similarity to real-world
applications"
- Bart
--
Bart Smaalders
this very well in his "Advanced Programming in the Unix
Environment" on page 178
Thanks... I need to patch this; we've hit this before.
I wish gcc would grok either
#pragma unknown_control_flow(setjmp)
or
extern void longjmp(jmp_buf, int) __NORETURN;
- Bart
--
Bart Smaal
rking, maybe I could copy some of your ideas.
This message posted from opensolaris.org
___
perf-discuss mailing list
perf-discuss@opensolaris.org
libmicro ports very easily; it's a good place to start
- Bart
--
Bart Smaalders
kind of hardware are you running on?
- Bart
--
Bart Smaalders Solaris Kernel Performance
[EMAIL PROTECTED] http://blogs.sun.com/barts
___
perf-discuss mailing list
perf-discuss@opensolaris.org
meone at Sun who has the event port zen to provide patches to
libevent
This message posted from opensolaris.org
This is a good idea. One of us will take a look at what is needed.
-= Bart
--
Bart Smaalders Solaris Kernel Performance
[EMAIL PROTECTED]
down one-shot timer that generates high level interrupts
to match.
- Bart
--
Bart Smaalders Solaris Kernel Performance
[EMAIL PROTECTED] http://blogs.sun.com/barts
___
perf-discuss mailing list
perf-discuss@opensolaris.org
352%
Total 522126 2039
Physical 522124 2039
- Bart
--
Bart Smaalders Solaris Kernel Performance
[EMAIL PROTECTED] http://blogs.sun.com/barts
___
perf-dis
are below 4G.
- Bart
--
Bart Smaalders Solaris Kernel Performance
[EMAIL PROTECTED] http://blogs.sun.com/barts
___
perf-discuss mailing list
perf-discuss@opensolaris.org
, but those didn't show up until Solaris 10. I'll
add a mechanism to make ELIDED_BENCHMARKS in Makefile.
release specific so that we can avoid this sort of problem.
In the meantime, add atomic to ELIDED_BENCHMARKS in Makefile.SunOS
to compile on Solaris 9.
- Bart
--
ris are you compiling?
- Bart
--
Bart Smaalders Solaris Kernel Performance
[EMAIL PROTECTED] http://blogs.sun.com/barts
___
perf-discuss mailing list
perf-discuss@opensolaris.org
cro page in the perf community
w/ a tarball.
Do remember, of course, that current OpenSolaris bits
are debug, so performance measurements are problematic
except with respect to comparisons against another build
of OpenSolaris.
Have fun -
- Bart
--
Bart Smaalders Solaris Ker
57 matches
Mail list logo
