(sound of lightbulb warming up) Ah, well, then could part of the issue
be that delay_sig(1) assumes one tick=10 ms? In these particular boxes,
hires_tick is on. Does that affect things?
So even if I reduce core_chunk its gonna run pretty hot in terms of cpu
cycles. Could something like this work if I had a dtrace script running?
dtrace -w -n 'fbt:genunix:core:enter {curlwpsinfo->pr_pri=0;}'
In the long run, of the intent is to give up the cpu for ~10 ms here,
wouldn't the right thing to query something internal to determine the
right number of ticks to pass here, rather that "1"?
Thanks
-d
> -----Original Message-----
> From: Bart Smaalders [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, April 19, 2006 12:29 PM
> To: David McDaniel (damcdani)
> Cc: [EMAIL PROTECTED]; Philip Beevers; [email protected]
> Subject: Re: [perf-discuss] Means to reduce core-dumping
> impact on performance critical system?
>
> Eric Lowe wrote:
> > David McDaniel (damcdani) wrote:
> >> I'd try to use dtrace to get more insight but I cant figure out
> >> where to start since I cant find the place(s) in the
> kernel where the
> >> dumping is actually taking place.
> >
> > core() -> do_core() -> {struct execsw->exec_core()} -> elfcore() ->
> > core_write()
> >
> > core() is called from kernel fault context (trap() -> psig() or
> > kern_gpfault() on x86/64, or trap_cleanup() on sun4*) which
> explains
> > why it's priority 60.
> >
> > - Eric
>
> The core dump loop does call delay_sig(1); this should wait
> for .01 seconds between each write 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/o
> s/core.c#core_chunk
>
> DTrace is your friend here as well...
>
> - Bart
>
>
> --
> Bart Smaalders Solaris Kernel Performance
> [EMAIL PROTECTED] http://blogs.sun.com/barts
>
_______________________________________________
perf-discuss mailing list
[email protected]
