DragonFly commits List (threaded) for 2006-12
DragonFly BSD
DragonFly commits List (threaded) for 2006-12
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: cvs commit: src/sys/dev/disk/nata ata-all.c


From: "Simon 'corecode' Schubert" <corecode@xxxxxxxxxxxx>
Date: Thu, 14 Dec 2006 01:04:03 +0100

Matthew Dillon wrote:
:why do we have to call the ctor and dtor anyways?  why not do if (oc->cto=
:r) oc->ctor(obj); ?  or am i missing something important there?
:
:cheers
:  simon

    I was operating under the assumption that the objcache would normally
    have a ctor / dtor function, so I didn't want to add another conditional
    to that path.  This isn't entirely true any more... or rather, only
    the mbuf subsystem really uses the feature.

    Ok, I AM a bit on the fence here.  I know that implementing M_ZERO adds
    one conditional to the hot path, but the M_ flags (like M_NOWAIT) are
    kinda integral to the allocation subsystem and I don't want to throw
    one away just to save a few nanoseconds.

I agree. M_NOWAIT is important to obey, but that's also no problem. I think we can safely assume that all consumers of object cache functions do know what they want and simply disallow M_ZERO. That's no big deal, because we don't have any of such consumers anyways. The whole concept of an object cache collides with using M_ZERO. Really, if you want to zero out data, use bzero. IIRC, M_ZERO also just optimizes page-sized allocations with kmalloc(), even if. Everybody who is using objects should be using them the right way, which implies not using M_ZERO.


cheers
 simon

--
Serve - BSD     +++  RENT this banner advert  +++    ASCII Ribbon   /"\
Work - Mac      +++  space for low €€€ NOW!1  +++      Campaign     \ /
Party Enjoy Relax   |   http://dragonflybsd.org      Against  HTML   \
Dude 2c 2 the max   !   http://golden-apple.biz       Mail + News   / \

Attachment: signature.asc
Description: OpenPGP digital signature



[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]