Hi!
Does |sun_prefetch_read_many()| have any effect on x86 machines ? If
"yes" - are there any CPU/vendor/compiler requirements for this ?
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland.ma...@nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ T
Hi!
Does gcc in Solaris have a similar builtin function as Sun
Studio/Forte/Workshop's |sun_prefetch_read_many()| which works on both
x86 and SPARC ?
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland.ma...@nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O
Glenn Fowler wrote:
>
> I think the point is that if the common usage is to
> sum many different files, or one file at a time over
> long spans of time then the performance of getting
> the bytes from the filesystem to user space may
> outweigh any cache optimization gains
>
> the ast apps are al
Glenn Fowler wrote:
[I split the email thread into multiple topics]
> I think the point is that if the common usage is to
> sum many different files, or one file at a time over
> long spans of time then the performance of getting
> the bytes from the filesystem to user space may
> outweigh any cach
Phil Harman wrote:
> Roland Mainz wrote:
> > Peter Tribble wrote:
> >> On Thu, Sep 10, 2009 at 8:38 AM, Raymond Wong wrote:
> >>
> > [snip]
> >
> >> while read a
> >> do
> >>line=$(($line+1))
> >> done
> >
&
Peter Tribble wrote:
> On Thu, Sep 10, 2009 at 8:38 AM, Raymond Wong wrote:
[snip]
> while read a
> do
>line=$(($line+1))
> done
This will run even faster if you remove the '$', put the assignment
inside the arithmetric expression and declare "line" as integer
variable, e.g. ...
-- snip --
Rod Evans wrote:
> Roland Mainz wrote:
> > Assuming I have application "foo" which originally only depended on
> > libc.so.1 and now I have a new version of "foo" which requires us to
> > load two more shared libraries (called libxxx1.so.1 and libyyy2.s
Hi!
Attached (as "cmd_benchmark_20090730_001.txt") are some preliminary
benchmark results and the script used to create it
("cmdbenchmark.sh.txt", the script still needs some cleanup and
extensions (e.g. cleanup, adding command-line options to modify the test
file size, number of loop itera
Garrett D'Amore wrote:
> Bob Friesenhahn wrote:
> > On Fri, 10 Jul 2009, Roland Mainz wrote:
[snip]
> I agree that we should *not* have the pipe(2) system call change the
> system default... that would be potentially destructive to many
> applications, as you note.
BTW: M
"I. Szczesniak" wrote:
> On 7/10/09, Bob Friesenhahn wrote:
[snip]
> > More importantly, why is it that ksh93 has a performance problem with pipes
> > when other shells do not? Is it actually demonstrated to have a performance
> > problem or is it conjecture?
>
> Roland?
See
http://mail.opensol
Bob Friesenhahn wrote:
[snip]
> More importantly, why is it that ksh93 has a performance problem with
> pipes when other shells do not? Is it actually demonstrated to have a
> performance problem or is it conjecture?
This isn't a specific ksh93 problem (that's why I started the disucssion
in shel
rickey c weisner wrote:
> On Fri, Jul 10, 2009 at 10:48:29AM -0500, Bob Friesenhahn wrote:
> > On Fri, 10 Jul 2009, Roland Mainz wrote:
> >>>
> >>> Some applications may misbehave or lock-up if the size of the pipe
> >>> buffer is changed.
> >&
"I. Szczesniak" wrote:
> On 7/10/09, Garrett D'Amore wrote:
> > Bob Friesenhahn wrote:
> > > On Fri, 10 Jul 2009, Roland Mainz wrote:
> > > > > Some applications may misbehave or lock-up if the size of the pipe
> > > > > buffer is cha
Garrett D'Amore wrote:
> Bob Friesenhahn wrote:
> > On Fri, 10 Jul 2009, Roland Mainz wrote:
> >>>
> >>> Some applications may misbehave or lock-up if the size of the pipe
> >>> buffer is changed.
> >>
> >> Erm... why ?
>
Bob Friesenhahn wrote:
> On Fri, 10 Jul 2009, Roland Mainz wrote:
> >> Some applications may misbehave or lock-up if the size of the pipe
> >> buffer is changed.
> >
> > Erm... why ?
>
> You have already noticed that the size is hard-coded in Solaris
> ap
Garrett D'Amore wrote:
> Roland Mainz wrote:
> > Bob Friesenhahn wrote:
> >> On Fri, 10 Jul 2009, Roland Mainz wrote:
> >>> Does anyone know where the default buffer size for pipes (e.g. $ ulimit
> >>> -p #) is defined and how it can be changed
Bob Friesenhahn wrote:
> On Fri, 10 Jul 2009, Roland Mainz wrote:
> > Does anyone know where the default buffer size for pipes (e.g. $ ulimit
> > -p #) is defined and how it can be changed (or turned into a system
> > tuneable) ? The current default of 5120 bytes is AFAIK n
Hi!
[REPOST - the first email had the address for
wrong (sorry)]
[CC:'ing Garrett D'Amore since he did some initial
digging on this subject earlier today]
Does anyone know where the default buffer size for pipes (e.g. $ ulimit
-p #) is defined and how it can be changed (or turned into a
Hi!
[CC:'ing Garrett D'Amore since he did some initial
digging on this subject earlier today]
Does anyone know where the default buffer size for pipes (e.g. $ ulimit
-p #) is defined and how it can be changed (or turned into a system
tuneable) ? The current default of 5120 bytes is AFAIK n
Bob Friesenhahn wrote:
> On Fri, 10 Jul 2009, Roland Mainz wrote:
> > - "tail" _may_ now be a bit slower since it no longer uses |mmap()|
> > (which was one of the root causes for crashes (e.g. if the underlying
> > file shrinks while "tail" reads it))
Milan Jurik wrote:
> V Ä?t, 09. 07. 2009 v 15:21, Sean McGrath pÃÅ¡e:
> > With the coming ksh93 update 2 and it replacing several commands
> > like wc, tail, head, join etc. Theres a need to have a benchmark
> > to measure at least before and after ksh93 update 2 change.
> >
> > Roland and
Hi!
Assuming I have application "foo" which originally only depended on
libc.so.1 and now I have a new version of "foo" which requires us to
load two more shared libraries (called libxxx1.so.1 and libyyy2.so.9)
... is there a way to reduce the additional startup time needed to load
these li
Matthew Flanagan wrote:
> I'm trying to track down the source of a performance problem with an
> application. The application in question is from a firewall vendor and the
> component of it that is suffering is the log handling daemon. The log daemon
> is single threaded and receives logs from f
johan...@sun.com wrote:
> On Tue, May 12, 2009 at 01:33:15AM +0200, Roland Mainz wrote:
> > Can you check whether the memory allocator in libast performs better in
> > this case (e.g. compile with $ cc -I/usr/include/ast/ -last ... # (note:
> > libast uses a |_ast_|-prefix for
Bob Friesenhahn wrote:
> On Tue, 12 May 2009, Roland Mainz wrote:
> > Can you check whether the memory allocator in libast performs better in
> > this case (e.g. compile with $ cc -I/usr/include/ast/ -last ... # (note:
> > libast uses a |_ast_|-prefix for all symbols and
Roland Mainz wrote:
> johan...@sun.com wrote:
> > On Mon, May 11, 2009 at 11:10:37AM -0500, Bob Friesenhahn wrote:
[snip]
> > There have been some past discussions on this list about identifying
> > problems with memory allocations, and applications that allocate memory
> &
johan...@sun.com wrote:
> On Mon, May 11, 2009 at 11:10:37AM -0500, Bob Friesenhahn wrote:
> > It seems that the performance issue stems from libumem using memory
> > mapped allocations rather than sbrk allocations. I have not seen a
> > performance impact from using libumem in any other part of t
Ben Rockwood wrote:
>
> I was doing some NFS benchmarking over the weekend with undesirable
> results. I thought that I'd use a share from tmpfs in order to contrast
> my results. I expected line speed NFS performance... but the results
> were horrible, far slower than any disk-based NFS benchma
Shawn Walker wrote:
> 2008/6/24 Roland Mainz <[EMAIL PROTECTED]>:
> > Technically there was an discussion on the last OpenSolaris.org summit
> > to check whether it may sense to replace libc's malloc implementation
> > with the libast one since it's faster, wo
[EMAIL PROTECTED] wrote:
>
> > Could you try an experiment and compile you sources with
> > /usr/lib/libast.so.1 (you need to compile the sources with
> > -I/usr/include/ast before /usr/include/ since libast uses a different
> > symbol namespace and cannot be used to "intercept" other
> > |malloc(
Matty wrote:
> On Wed, Apr 30, 2008 at 6:26 PM, David Lutz <[EMAIL PROTECTED]> wrote:
> > If your application is single threaded, you could try using the
> > bsdmalloc library. This is a fast malloc, but it is not multi-thread
> > safe and will also tend to use more memory than the default
> >
Bart Smaalders wrote:
> William James wrote:
[snip]
> > Remember what Bruno Jargot wrote about performance and POSIX:
> > |ksh93 is superior in functionality, performance and usability
> > |compared to bash.
> > |
> > |A few numbers:
> > |$ time bash -c 'i=0 ; s="" ; while [ $i -lt 1 ] ; do i=$
Kugutsumen wrote:
> On this quad core box with 8 gig of ram and a 4 gig zfs ARC, I keep seeing
> tons of cross calls and cpu migration.
>
> cross calls go up to 4000 during read only operations and up to 3 during
> read and write operations.
>
> The only thing running is postgresql and a si
Rafael Vanoni wrote:
> Roland Mainz wrote:
> > Rafael Vanoni wrote:
> >> Roland Mainz wrote:
> >>> Jonathan Chew wrote:
> >>>> Rafael Vanoni wrote:
> > [snip]
> >>> BTW: How does the topology code handle DR ?
> >> Take a lo
Rafael Vanoni wrote:
> Roland Mainz wrote:
> > Jonathan Chew wrote:
> >> Rafael Vanoni wrote:
[snip]
> > BTW: How does the topology code handle DR ?
>
> Take a look at
> http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/os/lgrp.c#522.
Steve Sistare wrote:
>
> This is a known issue on Solaris/x86. The issue is that over time,
> non-relocatable kernel memory is allocated at physical addresses
> throughout memory, fragmenting the PA space, and preventing the
> allocation of a physically contiguous large page.
[snip]
AFAIK a lar
Jonathan Chew wrote:
> Rafael Vanoni wrote:
> > Hey everyone
> >
> > Is the kernel aware of the status of the interconnect between different
> > NUMA nodes ?
>
> No, not currently. It just assumes that there is some interconnect
> between the nodes and may know the latency between them when the s
"Ostrovsky, Boris" wrote:
> > On Nov 1, 2007 5:33 PM, Roland Mainz <[EMAIL PROTECTED]> wrote:
> > > I was referring to something I read recently in a german computer
> > > magazine tha the upcoming AMD CPUs have some kind of special 128 FP
> > >
Boris Ostrovsky wrote:
> Roland Mainz wrote:
> > ... it may be nice to see the new AMD64 128bit floating-point stuff
> > supported in Solaris... may be a usefull for HPC customers... :-)
>
> There is no need to change anything in software to take advantage of
> wider
Roland Mainz wrote:
> Jens Elkner wrote:
> [Please keep [EMAIL PROTECTED] in the CC: field
> for AST/ksh93-related topics since not all people there are subscribed
> to all other opensolaris-org lists, too]
> > On Wed, Oct 31, 2007 at 01:25:36AM -0400, Peter Memishian wrote:
"Ostrovsky, Boris" wrote:
> I would like to propose creation of a new project titled "Solaris
> Enhancements for AMD-based Platforms".
>
> The project will address various features that are specific to platforms
> based on AMD processors, such as
> - IOMMU support
> - NUMA topology
Fintan Ryan wrote:
[Please keep [EMAIL PROTECTED] in the CC: field
for AST-related topics since not all people there are subscribed to all
other opensolaris-org lists, too]
> >>> Linux i6860.704u 0.004s 0:00.70 100.0%5587 ms
> >>> 2079.593
> >> 1. Which locale do you use ?
>
Jens Elkner wrote:
[Please keep [EMAIL PROTECTED] in the CC: field
for AST-related topics since not all people there are subscribed to all
other opensolaris-org lists, too]
> On Wed, Oct 31, 2007 at 01:04:55PM -0400, Glenn Fowler wrote:
> > > Jens Elkner wrote:
> > > > regex.c
Jens Elkner wrote:
[Please keep [EMAIL PROTECTED] in the CC: field
for AST/ksh93-related topics since not all people there are subscribed
to all other opensolaris-org lists, too]
> On Wed, Oct 31, 2007 at 01:25:36AM -0400, Peter Memishian wrote:
> > > /usr/lib/libast.so.1 before you can link with
Hi!
[Please keep [EMAIL PROTECTED] in the CC: field
for AST-related topics since not all people there are subscribed to all
other opensolaris-org lists, too]
Jens Elkner wrote:
> On Wed, Oct 31, 2007 at 06:20:02AM +0100, Roland Mainz wrote:
> > Jens Elkner wrote:
> >
Peter Memishian wrote:
>
> > 1. Which locale do you use ?
> > 2. Starting with Solaris 11/B72 there is libast.so.1 which comes with an
> > own set of pattern matching functions. It may be nice to check how these
> > functions perform compared to the "normal" Solaris functions in libc.
> > Not
Jens Elkner wrote:
[CC:'ing [EMAIL PROTECTED] since libast belongs
to this project]
>
> regex.c RegexTest.javaMHz
> Solaris sparc13.12u 0.01s 0:13.17 99.6%5569 ms 1503
> Solaris x86 6.28u 0.00s 0:06.29 99.8%2571 ms
Shawn Walker wrote:
> On 19/07/07, Stephen Hahn <[EMAIL PROTECTED]> wrote:
> > * Roland Mainz <[EMAIL PROTECTED]> [2007-07-19 17:01]:
> > > Alexander Kolbasov wrote:
> > > > > "Richard L. Hamilton" wrote:
[snip]
> > There's probab
Stephen Hahn wrote:
> * Roland Mainz <[EMAIL PROTECTED]> [2007-07-19 17:01]:
> > Alexander Kolbasov wrote:
> > > > "Richard L. Hamilton" wrote:
[snip]
> > > Perl has a mechanism (called XSUB) to write glue code between C and Perl.
> > > It
Stefan Parvu wrote:
> > Wow, I thought you were about to encourage something like:
> > - use of the SE Toolkit
> > - making libproc a stable interface
> > - adding a Sun::Solaris::Proc to Perl
>
> +1
> Sun::Solaris::Proc might be a nice thing to have in Perl.
I agree... but I ho
Brendan Gregg - Sun Microsystems wrote:
> On Fri, Jul 20, 2007 at 11:49:07PM +0200, Roland Mainz wrote:
[snip]
> > Now I am wondering whether it may be usefull to put all the tools in
> > /usr/proc/bin/ and /usr/bin/ps in a seperate "procsh" (= "process shell"
&g
Hi!
This is an old idea based on the observation that many process
monitoring tools or scripts are more or less |fork()|-bombs, for example
sdtprocess calls /usr/bin/ps for each cycle and other tools use many of
the tools in /usr/proc/bin/ to collect information, process them through
variou
"Richard L. Hamilton" wrote:
[snip]
> > This email and any files transmitted with it are
> > confidential and intended solely for the use of the
> > individual or entity to whom they are addressed. If
> > you have received this email in error please notify
> > the system manager. This message conta
Alexander Kolbasov wrote:
> > "Richard L. Hamilton" wrote:
> > >
> > > [...]
> > > > Hence, I totally agree with...
> > [snip]
> > > >From my point of view, function-call-like APIs that deal with binary
> > > data, preferably available in both C and perl (the latter for those for
> > > whom everyth
"Richard L. Hamilton" wrote:
>
> [...]
> > Hence, I totally agree with...
[snip]
> >From my point of view, function-call-like APIs that deal with binary
> data, preferably available in both C and perl (the latter for those for
> whom everything has to be some sort of script), are preferable to
> n
Richard McDougall wrote:
> On Wed, May 30, 2007 at 11:57:52PM +0200, Roland Mainz wrote:
> > Is there anyone interested to help with a small project to add a new
> > scheduler class for batch jobs, e.g. a "bt" (=batch) scheduler class ?
> > The idea would be to cre
[EMAIL PROTECTED] wrote:
> On Wed, May 30, 2007 at 11:57:52PM +0200, Roland Mainz wrote:
> > Is there anyone interested to help with a small project to add a new
> > scheduler class for batch jobs, e.g. a "bt" (=batch) scheduler class ?
> > The idea would be to cre
Hi!
Is there anyone interested to help with a small project to add a new
scheduler class for batch jobs, e.g. a "bt" (=batch) scheduler class ?
The idea would be to create something where the process members of this
class are given longer timeslices but can be preempted by any
timeshareing
Eric Saxe wrote:
> Roland Mainz wrote:
> > Eric Saxe wrote:
> >> Roland Mainz wrote:
> >>> Is there any special handling of process groups to make sure that
> >>> processes (and their LWPs) are kept together ?
> >>>
> >>> Thin
Phil Harman wrote:
[snip]
> 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).
BTW: It may be nice to think about adding more than one API for such
cases. For
Eric Enright wrote:
> On 1/29/07, Bruno Jargot <[EMAIL PROTECTED]> wrote:
> > On 1/29/07, Michelle Olson <[EMAIL PROTECTED]> wrote:
> > > Hi Rich,
[snip]
> Waiting a little extra time to receive the archive is far better than
> waiting a lot of extra time to unpack it.
Offtopic: Both gzip and bzip
Eric Saxe wrote:
> Roland Mainz wrote:
> > Is there any special handling of process groups to make sure that
> > processes (and their LWPs) are kept together ?
> >
> > Think about an (imaginary (and simplified)) machine with 4 strands per
> > core, 4 cores per
Hi!
Is there any special handling of process groups to make sure that
processes (and their LWPs) are kept together ?
Think about an (imaginary (and simplified)) machine with 4 strands per
core, 4 cores per socket, 4 sockets per board and 4 boards per cabinet
and 4 cabinets where each layer
Hi!
Is it possible to use |recv()| in Solaris on a normal pipe (see attached
email, it may be somewhat performace-critical for shell scripts) ?
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) [EMAIL PROTECTED]
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL
David Comay wrote:
> Can I ask why you feel bumping up the optimization level is necessary for
> ksh93
> and friends?
Because ksh is used very often during Solaris boot and runtime so it has
some importance for me to look at performance and footprint and try to
optimize this...
> I would instead
Jonathan Adams wrote:
> > > - Create a C macro |#define KMEM_TMP_ALLOC()| which expands to the
> > > following procedure:
> > > 1. Measure stack size and current available space on stack. The first
> > > 512bytes (of a 8k default stack, a 64k default stack would offer much
> > > more room (this val
Jonathan Adams wrote:
>
> On Mon, Jul 10, 2006 at 11:35:31AM -0700, Alexander Kolbasov wrote:
> > > [EMAIL PROTECTED] wrote:
> > > > >Offtopic: Which still reminds me to write an email about that the
> > > > >Solaris kernel is very very malloc()-happy (which is unneccesary in
> > > > >many
> > >
Alexander Kolbasov wrote:
> > Create a C macro |#define KMEM_TMP_ALLOC()| which expands to the
> > following procedure:
> > 1. Measure stack size and current available space on stack. The first
> > 512bytes (of a 8k default stack, a 64k default stack would offer much
> > more room (this value is a
Hi!
While looking at "isaexec" machinery which selects the ksh93 binary to
be used I realised that it uses /usr/bin/i86/ksh93 on a Solaris version
which supports as minimum version the Intel Pentium-1 (or higher) ...
... my proposal would be to bump the default optimisation settings up to
[EMAIL PROTECTED] wrote:
> >Offtopic: Which still reminds me to write an email about that the
> >Solaris kernel is very very malloc()-happy (which is unneccesary in many
> >cases now that C99-sematics are allowed).
>
> You are wrong.
Thank you... ;-((
See below...
> We *malloc* not because of sh
70 matches
Mail list logo
