Eric C. Saxe wrote:
Hey look at that. My previous message has been robbed of line breaks
and the first part of
this thread has gone missing. Looks like the html I embedded really
confused things. Here's
a more readable version of my last message. I'll let Derek know that
this thread needs to b
Hey look at that. My previous message has been robbed of line breaks and the
first part of
this thread has gone missing. Looks like the html I embedded really confused
things. Here's
a more readable version of my last message. I'll let Derek know that this
thread needs to be fixed...
-Eric
On
I think that the pipe test for libMicro can be enhanced a bit by
- Adding support for PF_UNIX/SOCK_DGRAM sockets
They are used by various applications and it is interesting to measure
performance differencies from other loopback-type transports
- Adding support for ptys as a loopback pipe me
Trying to do
$ make run
produced:
make: Fatal error: Don't know how to make target `run'
Current working directory /net/aldan/export/akolb/build/libMicro-0.3.0/bin-i86pc
*** Error code 1
The following command caused the error:
mkdir -p bin-`uname -m`; cd bin-`uname -m`; MACH=`uname -m` make -f
On 8/8/05, Ben Cooper <[EMAIL PROTECTED]> wrote:
> I thought it would be interesting to get these
> running on Mac OS X/
> PPC since there's no Darwin makefile included in the
> release.
Hey, this is really great.
> So the tests compiled and ran, but as soon as I got
> to the fork I got
> resourc
Nice.
I had some thoughts on this. I noticed that Filebench and libMicro were
similar, but different. I think it would be a Good Idea to converge on a
common output format.
For example, I like the 'tattle' header from libMicro, which tells me
absolutely everything I need to know (hopefull
Ben,
Eric is looking into the limits question, so I hope to see an answer posted
from him soon.
In the mean time, thanks much for the diffs for Darwin! Can I get you to sign
a contributor agreement (located here:
http://opensolaris.org/os/about/sun_contributor_agreement/) and fax it in, so
It's obviously the week of Open Source benchmarks :-) I've just added the
FileBench page to the performance community, and links to the source and binary
downloads.
http://opensolaris.org/os/community/performance/filebench
It's still early days for filebench; we are honing the workload list as
The first prototype of NUMA-aware ptools (plgrp(1), pmadvise(1) and
lgroup-aware pmap(1) extensions) is available for download at
http://www.opensolaris.org/os/community/performance/numa/observability
This is work in progress. Please send your comments/suggestions, flames to
http://www.openso
Ryan:
The goodness of UFS direct I/O is highly application-specific. The benefits
arise from two fundamental
reasons - one being avoidance of OS page cache scaling limitations, and the
other being removal
of the POSIX single-writer lock constraint - which allows multiple I/O
operations to a fi
Matty's email at 8/8/2005 3:52 PM, said:
Howdy,
While reading through Solaris Internals this weekend, I came to the
section on UFS direct I/O. The book states that random and large
sequential workloads benefit from direct I/O. Does anyone happen
to know how big a "large sequential" I/O needs t
> 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
> <
12 matches
Mail list logo
