Bummer. I should have tried this before even asking about it :-(
# dtrace -w -n 'fbt:genunix:core:entry {curlwpsinfo->pr_pri=0;}'
dtrace: invalid probe specifier fbt:genunix:core:entry
{curlwpsinfo->pr_pri=0;}: in action list: operator = can only be applied
to a writable variable
#
Does the notion of scheduler priority even apply here? If so, any
suggestion as to how I might tweak it here would be greatly appreciated.
Thanks.
Regards
-d
> -----Original Message-----
> From: David McDaniel (damcdani)
> Sent: Friday, April 21, 2006 1:04 PM
> To: 'Bart Smaalders'
> Cc: [EMAIL PROTECTED]; Philip Beevers; [email protected]
> Subject: RE: [perf-discuss] Means to reduce core-dumping
> impact on performance critical system?
>
> (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:entry {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]
