Date: Mon, 22 Jan 2007 00:30:40 +0100 From: "Attilio Rao" <attilio@freebsd.org> To: "Luigi Rizzo" <rizzo@icir.org> Cc: Ivan Voras <ivoras@fer.hr>, freebsd-arch@freebsd.org Subject: Re: bzero & bcopy alignment Message-ID: <3bbf2fe10701211530o7c2e8977k2df02a546cb4cb8f@mail.gmail.com> In-Reply-To: <20070121152251.A84413@xorpc.icir.org> References: <ep0mlv$194$1@sea.gmane.org> <20070121140019.A83688@xorpc.icir.org> <ep0p8i$86q$1@sea.gmane.org> <20070121152251.A84413@xorpc.icir.org>
next in thread | previous in thread | raw e-mail | index | archive | help
2007/1/22, Luigi Rizzo <rizzo@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).
Attilio
--
Peace can only be achieved by understanding - A. Einstein
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3bbf2fe10701211530o7c2e8977k2df02a546cb4cb8f>