The difference is mostly because Solaris also uses free memory as a virtual
swap device, and you have quite a lot of free memory.
As free memory is consumed, your configured swap devices will be used as a
secondary preference.
You also need to understand the difference between reserved, allocat
On 14/07/2010 19:24, johan...@opensolaris.org wrote:
On Wed, Jul 14, 2010 at 01:12:37PM -0500, Nicolas Williams wrote:
On Wed, Jul 14, 2010 at 11:06:38AM -0700, johan...@opensolaris.org wrote:
On Tue, Jul 13, 2010 at 06:41:32PM -0500, Nicolas Williams wrote:
As to your questi
, bla(), bla(), bla(), bla(),
vfork(), exec() applications and shells have to use today.
Olga
2010/7/12 Phil Harman:
This was one of my pet peeves during my 20 years at Sun. The main reason I wanted spawn(2) was for
multithreaded apps needing to start new processes. The issue was that all LWPs
This was one of my pet peeves during my 20 years at Sun. The main reason I
wanted spawn(2) was for multithreaded apps needing to start new processes. The
issue was that all LWPs need to be quiesced before even a vfork(2), which meant
that something as simple as just calling system(3) might stop
I see at least two differences:
1. duration 30s vs 100s (so not "SAME")
2. your manual test doesn't empty the cache
Of course, it is the latter that makes all the difference.
Hope this helps,
Phil
Sent from my iPhone
On 2 Mar 2010, at 08:38, Abdullah Al-Dahlawi wrote:
Greeting All
I am u
Whilst true, it pales compared to the inefficiency of executing external
commands. I've always preferred the (( a = a + 1 )) construct because it
is slightly more readable. Nice to know that there's a performance
reason for doing it too. Thanks for sharing.
Phil
Roland Mainz wrote:
Peter Tr
Peter Tribble wrote:
On Thu, Sep 10, 2009 at 8:38 AM, Raymond Wong wrote:
Hi,
Thanks for taking a look.
The SPARC system is a Sun V440 with 4 CPUs and 16GB of RAM. The normal CPU load
is about 50% and minimal disk activity.
What the script does is to go through a text file and get the beg
Can you be more specific about the SPARC system? Can you share some or
all of the script with us? Maybe you could tell us a little more about
what it does?
On 10 Sep 2009, at 07:40, Raymond Wong wrote:
Hi,
I am experiencing poor performance on our Solaris 10 installation.
The bash scri
Comments inline.
Matthew Flanagan wrote:
Hi Phil
Matthew,
In addition to Roland's comment about patching (which
is particularly
important due to the rate of change in ZFS) ...
1) Your dd test doesn't really tell us much. Do you
know what size
writes fwd is doing? I doubt it is 128k. You
Matthew,
In addition to Roland's comment about patching (which is particularly
important due to the rate of change in ZFS) ...
1) Your dd test doesn't really tell us much. Do you know what size
writes fwd is doing? I doubt it is 128k. You could use truss/dtrace to
find out and then use dd ag
Old news, I'm afraid. Any consumer of the cpu sys kstats will seem the
same thing. I guess some people just didn't notice until we started
discussing it :)
At least I managed to get wt permanently set to zero ...
4518644 I/O wait statistic is still misleading and should be dropped
http://bu
If you really need it to add up to 100, then it's simple ...
if (Kernel + User > 100) {
User = 100 - Kernel;
}
Idle = 100 - Kernel - User;
If you want to be smart, you might want to round small numbers up, and
large numbers down (e.g. perhaps any non-zero amount should always
guoqingzhu wrote:
> Hi, can anyone help tell me about this?
> I want to test my raw disk IO performance using 'dd' or other tools like
> vdbench. But I don't know which device file should be correct, or both OK.
> What about the difference between these two file when I do dd to them?
> In my opi
The default resolution of nanosleep(3RT) of 10ms, because it is
implemented using the clock interrupt. Note the following from the
manpage ...
The
suspension time may be longer than requested because the
argument value is rounded up to an integer multiple of the
sleep res
Author: [EMAIL PROTECTED]
Repository: /hg/libmicro/libmicro
Latest revision: fd7fac22e44123e28d59b3a67d5b8e52e09bbc62
Total changesets: 1
Log message:
small changes to make USE_RDTSC work again
Files:
update: bench.sh
update: libmicro.c
update: libmicro.h
__
Robert,
I'm currently working on some enhancements for libc's malloc() (and
friends) which are primarily targeted at improving packing and thread
scalability for small allocations (1-128 bytes).
I haven't given realloc() much consideration, although I have noted that
some implementations und
Dan,
Great stuff. Thanks! I think we will be spinning a 0.3.1 sometime within
the next couple of weeks, and your changes will certainly be included.
I've got a few changes to make to the bench script (like putting
close_tcp last, maybe reintroducing -B for some cases, and so on).
There's also
libMicro knows of two barrier synchronisation methods. The prefered
method requires the platform to provide PTHREAD_PROCESS_SHARED mutexes
and condvars. Until recently (e.g. with the NPTL) Linux didn't support
this, so I implemented a SysV semop version as well. The default build
uses a shared
Dan Price wrote:
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
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_WRITE. I suspect one of these is cheap, and the other
is no
Bob Palowoda wrote:
Well, just one "thought" actually ...
I think we need a smaller batch size for the "connection" case.
Connections are very expensive, so I think a batch size of 10 (instead
of 256) would probably suffice.
Well yes but isn't that kind of hiding the anomaly?
I'm
Well, just one "thought" actually ...
I think we need a smaller batch size for the "connection" case.
Connections are very expensive, so I think a batch size of 10 (instead
of 256) would probably suffice.
Phil
smime.p7s
Description: S/MIME Cryptographic Signature
___
One big issue for repeatability at the moment (at least on Solaris) is
the issue of sockets left in TIME_WAIT state. By default I think they
hang around for two minutes.
Having lots of sockets in TIME_WAIT seems to have a big impact on
libMicro cases like "bind" and "connection". We did try to
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
process, not by the thread.
On 10/08/2005, at 10:37 PM, Phil Harman wrote:
And it is portable! We've had it running on Solaris (all platforms,
both 32-bit and 64-bit), Linux, AIX, HP-UX, MacOS X, and Windows XP
(using Microsoft's own Services For UNIX as well as the Cygnus
envir
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
Dave Marquardt wrote:
Gabriel Díaz wrote:
> How is possible to make a microbenchmark library portable?
> well, i mean, can i compile the lib on other OS and do the
> test agaist it, and compare results?
It's not a library, it's a collection of microbenchmarks. But I can
see why you might think
Ah! You've just stumbled on one of libMicro's vestigial organs (there
will be others). We scrapped the 'run' target ages ago. Sorry.
Cheers,
Phil
Alexander Kolbasov wrote:
Trying to do
$ make run
produced:
make: Fatal error: Don't know how to make target `run'
Current working directory /n
Yes indeed. Please do share useful extensions like this! Bart and I just
don't have the bandwidth (or desire) to do implement all this stuff
ourselves (which was a really big motivator in opening libMicro up to
the world).
Most of the cases you see in libMicro today arose from specific
invest
johansen wrote:
With Solaris 10, Sun undertook a very specific set of projects with the
explicit objective of improving the performance of small (1-2p) systems. I
can't speak for Phil, but in my experience performance engineers have always
chosen the solution which scales best, since we have
31 matches
Mail list logo
