low(er) disk performance with sched_4bsd then with sched_ule
scottl at samsco.org
Sat Sep 17 19:20:41 PDT 2005
Andrew Gallatin wrote:
> Oliver Lehmann writes:
> > Joseph Koshy wrote:
> > > ol> Wow, that update to BETA4 did the trick! While running
> > > ol> SCHED_4BSD:
> > >
> > > Fantastic! What is the profile like with the new 4BSD kernel?
> > http://pofo.de/tmp/gprof.4bsd.3
> I don't know the disk codepath very well, but the samples look a
> little suspect. We're copying a lot of data into and out of the
> kernel, so I would expect the majority of non disk wait time would be
> spent simply copying out the zero-filled pages, and copying them back
> in (AFAIK, dd uses read/write). Where is the time spent in read,
> write, uiomove, bcopy?
> What about ionode allocations, etc? And why do things like
> g_bsd_modify and g_bsd_ioctl rank so high? Aren't those only used
> when dealing with disklabels?
> BTW, I *love* that we've got access to the hw counters, and an easy
> way to do low-overhead profiling of the kernel.
I don't know if it's the case here or not, but GCC now does very
aggressive function inlining, so much so that it's nearly impossible
to look at a backtrace and figure out what the actual call path was.
Compiling with -O instead of the -O2 default turns off this 'feature'
(and I use that term quite liberally), so it might be useful to
recompile there kernel with 'CFLAGS= -O' in /etc/make.conf and see
if it changes the profiling numbers at all.
Also, I think that there was some talk last year about things like
preemption and fast interrupts screwing up certain kinds of profiling.
I don't recall if there was a solution to this, though.
More information about the freebsd-current