On Tue, 2009-02-24 at 12:01 -0500, erik quanstrom wrote:
> data would be helpful.
Indeed! Personally, I'm not old enough to have lived
through most of these wars to tell a story.
> nobody here has shown any version
> of solaris to be slow forking, much less that it is slow
> forking because of ac
> It could have been the "old" accounting. Solaris 10
> changed a lot of that and made things like microstate
> accounting on by default, thus, possibly eliminating
> the kind of bottlenecks the instructor was referring
> to. More on that here:
>http://blogs.sun.com/eschrock/entry/microstate_ac
On Tue, 2009-02-24 at 11:22 -0500, erik quanstrom wrote:
> > > cfork is ~525 lines long and seems to take the curious tack of
> > > forking all the lwps associated with a process.
> >
> > that would be forkall(), not fork1()/fork()
>
> my mistake. i assumed that since isfork1 was
> a flag, that
> > cfork is ~525 lines long and seems to take the curious tack of
> > forking all the lwps associated with a process.
>
> that would be forkall(), not fork1()/fork()
my mistake. i assumed that since isfork1 was
a flag, that it was not the normal path through
the code. silly me.
so where's th
On Tue, 2009-02-24 at 10:54 -0500, erik quanstrom wrote:
> > about 5 years ago i took a class on performance tuning Solaris.
> >
> > The instructor claimed that fork was expensive because accounting is never
> > really turned off, just piped to /dev/null. there is no accounting
> > overhead for
> about 5 years ago i took a class on performance tuning Solaris.
>
> The instructor claimed that fork was expensive because accounting is never
> really turned off, just piped to /dev/null. there is no accounting overhead
> for threads.
>
> I never bothered to verify this, but now that this c
On Fri, 20 Feb 2009, erik quanstrom wrote:
On Fri Feb 20 11:18:41 EST 2009, urie...@gmail.com wrote:
One of the main costs of dynamic linking is making fork much slower.
Even on linux statically linked binaries fork a few magnitude orders
faster than dynamically linked ones.
The main source of
On Fri Feb 20 11:18:41 EST 2009, urie...@gmail.com wrote:
> One of the main costs of dynamic linking is making fork much slower.
> Even on linux statically linked binaries fork a few magnitude orders
> faster than dynamically linked ones.
>
> The main source of anti-fork FUD turns out to be the al
One of the main costs of dynamic linking is making fork much slower.
Even on linux statically linked binaries fork a few magnitude orders
faster than dynamically linked ones.
The main source of anti-fork FUD turns out to be the alleged
'solution' to a problem that didn't exist until the geniuses a
> I believe that
> 1) Its too much trouble parsing the output everytime.
i don't buy that. that takes very little code. since you
have evidently already written the code, the cost
is zero.
(if you're worried about runtime, i measure parsing
time at 338ns on a core i7 920. cf. attached digestsp
On Feb 19, 8:03 am, quans...@quanstro.net (erik quanstrom) wrote:
> what's wrong with the tools-based approach
> you're currently using?
>
> this may be hard to believe coming from unix,
> but your approach is what many tools do. nobody
> links to a tcs library. one uses the tcs(1)
> executable.
On Thu Feb 19 05:04:15 EST 2009, anooop.ano...@gmail.com wrote:
> Hello once again,
>
> I was wondering whether if there are any libraries that I can include
> to call vac and unvac directly from my C code. Currently I am
> executing them in the shell using popen and capturing the output. I am
> l
Hello once again,
I was wondering whether if there are any libraries that I can include
to call vac and unvac directly from my C code. Currently I am
executing them in the shell using popen and capturing the output. I am
looking for better ways.
~Anoop
13 matches
Mail list logo
