bzero & bcopy alignment

[Luigi Rizzo]

On Mon, Jan 22, 2007 at 12:30:40AM +0100, Attilio Rao wrote:
> 2007/1/22, Luigi Rizzo <rizzo at icir.org>:
> > On Sun, Jan 21, 2007 at 11:25:14PM +0100, Ivan Voras wrote:
> > > Luigi Rizzo wrote:
> > > > On Sun, Jan 21, 2007 at 10:41:09PM +0100, Ivan Voras wrote:
> > > >> Following recent discussion on alignment of bzero() and bcopy(), I've
> > > >> added some statistics collecting code to bzero() and bcopy() for
> > > >> practice (on a RELENG_6 box), and here are the cumulative results for
> > > >> argument alignment:
> > > >
> > > > i think these profiles depend heavily on the hardware
> > > > and usage patterns.
> > >
> > > Yes, I agree. For what it's worth, this was on vmware, almost no network
> > > activity.
> > >
> > > > e.g. some network drivers force you to aligned buffers
> > > > which results in misaligned payload requesting in
> > > > turn an unaligned bcopy. Not that one can help with this,
> > > > but i think that is also important to locate the locations
> > > > in the source where the poorly aligned (1-2, maybe
> > > > 4 and 8 to some degree) ops occur.
> > >
> > > Any magic tricks to identify the caller of "current" function in the kernel?
> >
> > i suppose i would remap those function as
> >
> > #define bcopy(a, b, c)                          \
> >        do {                                    \
> >                track_bcopy(__PRETTY_FUNCTION__, __FILE__, __LINE__, a, b, c);
> >                original_bcopy(a, b, c);
> >        }
> >
> > and the same for bzero, and then use function track_bcopy()
> > to simply record the instances in some data structure that you
> > can then export in some way to userland for stats gathering.
> > In the simplest form you could e.g. filter unaligned accesses
> > and just dump them to a buffer exported via sysctl;
> > if you want to make things smarter/more efficient, you could
> > hash __FILE__, __LINE__ to avoid duplicates (and probably,
> > because these are constant strings, you can just compare
> > the string pointers without having to do a full strcmp).
> 
> A better approach (at least for ia32, I'm not aware what is the
> situation on the other architectures) would be using the vectorized
> entry for this family of function (i386/include/md_var.h).

you still need the macro wrappers to acquire __FILE__ and __LINE__
information.

cheers
luigi