kmem_cache_alloc(9F) 使用

NAME

     kmem_cache_create,    kmem_cache_alloc,     kmem_cache_free,
     kmem_cache_destroy  -  kernel  memory cache allocator opera-
     tions


SYNOPSIS

     #include <sys/types.h>
     #include <sys/kmem.h>

     kmem_cache_t *kmem_cache_create(char *name, size_t bufsize,
         size_t align, int (*constructor)(void *, void *, int),
         void (*destructor)(void *, void *), void (*reclaim)(void *),
         void *private, void *vmp, int cflags);

     void kmem_cache_destroy(kmem_cache_t *cp);

     void *kmem_cache_alloc(kmem_cache_t *cp, intkmflag);

     void kmem_cache_free(kmem_cache_t *cp, void *obj);

      [Synopsis for callback functions:]

     int (*constructor)(void *buf, void *un, int kmflags);

     void (*destructor)(void *buf, void *un);


INTERFACE LEVEL

     Solaris DDI specific (Solaris DDI)


PARAMETERS

     The parameters for the kmem_cache_* functions  are  as  fol-
     lows:

     name           Descriptive name of a kstat(9S) structure  of
                    class  kmem_cache.  Only alphanumeric charac-
                    ters can be used in name.

     bufsize        Size of the objects it manages.

     align          Required object alignment.

     constructor    Pointer to an  object  constructor  function.
                    Parameters are defined below.

     destructor     Pointer to  an  object  destructor  function.
                    Parameters are defined below.

     reclaim        Drivers should pass NULL.

     private        Pass-through           argument           for
                    constructor/destructor.

     vmp            Drivers should pass NULL.

     cflags         Drivers must pass 0.

     kmflag         Possible flags are:

                    KM_SLEEP       Allow   sleeping    (blocking)
                                   until memory is available.

                    KM_NOSLEEP     Return  NULL  immediately   if
                                   memory is not available.

                    KM_PUSHPAGE    Allow the  allocation  to  use
                                   reserved memory.

     *obj           Pointer   to   the   object   allocated    by
                    kmem_cache_alloc().

     The parameters for the callback constructor function are  as
     follows:

     void *buf      Pointer to the object to be constructed.

     void *un       The  private  parameter  from  the  call   to
                    kmem_cache_create();   it   is   typically  a
                    pointer to the soft-state structure.

     int kmflags    Propagated kmflag values.

     The parameters for the callback destructor function  are  as
     follows:

     void *buf    Pointer to the object to be deconstructed.

     void *un     The  private  parameter  from   the   call   to
                  kmem_cache_create();  it is typically a pointer
                  to the soft-state structure.


DESCRIPTION

     In many cases, the cost of initializing  and  destroying  an
     object exceeds the cost of allocating and freeing memory for
     it. The functions described here address this condition.

     Object caching is a technique for dealing with objects  that
     are:

         o    frequently allocated and freed, and

         o    have setup and initialization costs.

     The idea is to  allow  the  allocator  and  its  clients  to
     cooperate  to  preserve the invariant portion of an object's
     initial state, or constructed state,  between  uses,  so  it
     does  not have to be destroyed and re-created every time the
     object is used. For example, an object  containing  a  mutex
     only needs to have mutex_init() applied once, the first time
     the object is allocated. The object can then  be  freed  and
     reallocated  many  times  without  incurring  the expense of
     mutex_destroy() and  mutex_init()  each  time.  An  object's
     embedded locks, condition variables, reference counts, lists
     of other objects, and read-only data all  generally  qualify
     as  constructed state. The essential requirement is that the
     client must free the object (using kmem_cache_free()) in its
     constructed  state.  The  allocator  cannot enforce this, so
     programming errors will lead to hard-to-find bugs.

     A driver should call  kmem_cache_create()  at  the  time  of
     _init(9E)   or   attach(9E),   and  call  the  corresponding
     kmem_cache_destroy() at the time of _fini(9E) or detach(9E).

     kmem_cache_create() creates a cache of objects, each of size
     size  bytes,  aligned  on  an  align  boundary.  Drivers not
     requiring a specific alignment can pass 0.  name  identifies
     the cache for statistics and debugging. constructor and des-
     tructor convert plain memory into objects  and  back  again;
     constructor can fail if it needs to allocate memory but can-
     not. private is a parameter passed to  the  constructor  and
     destructor  callbacks  to  support parameterized caches (for
     example, a pointer to an instance of the driver's soft-state
     structure).  To  facilitate  debugging,  kmem_cache_create()
     creates a kstat(9S) structure of class kmem_cache  and  name
     name. It returns an opaque pointer to the object cache.

     kmem_cache_alloc() gets an object from the cache. The object
     will be in its constructed state. kmflag has either KM_SLEEP
     or KM_NOSLEEP set, indicating whether it  is  acceptable  to
     wait for memory if none is currently available.

     A small pool of reserved memory is available  to  allow  the
     system  to  progress  toward  the goal of freeing additional
     memory while in a low memory situation. The KM_PUSHPAGE flag
     enables  use  of this reserved memory pool on an allocation.
     This flag can be used by drivers that implement strategy(9E)
     on  memory  allocations  associated with a single I/O opera-
     tion. The driver guarantees that the I/O operation will com-
     plete  (or timeout) and, on completion, that the memory will
     be returned. The KM_PUSHPAGE flag should  be  used  only  in
     kmem_cache_alloc() calls. All allocations from a given cache
     should be consistent in their use of the flag. A driver that
     adheres  to  these  restrictions can guarantee progress in a
     low memory situation without resorting  to  complex  private
     allocation and queuing schemes. If KM_PUSHPAGE is specified,
     KM_SLEEP can also be used without causing deadlock.

     kmem_cache_free() returns an object to the cache. The object
     must be in its constructed state.

     kmem_cache_destroy() destroys the  cache  and  releases  all
     associated  resources.  All allocated objects must have been
     previously freed.


CONTEXT

     Constructors   can   be   invoked   during   any   call   to
     kmem_cache_alloc(), and will run in that context. Similarly,
     destructors   can   be   invoked   during   any   call    to
     kmem_cache_free(),   and   can   also   be   invoked  during
     kmem_cache_destroy(). Therefore, the functions that  a  con-
     structor  or  destructor invokes must be appropriate in that
     context.

     kmem_cache_create() and  kmem_cache_destroy()  must  not  be
     called from interrupt context.

     kmem_cache_alloc() can be called from interrupt context only
     if the KM_NOSLEEP flag is set. It can be called from user or
     kernel context with any valid flag.

     kmem_cache_free() can be called from user, kernel, or inter-
     rupt context.


EXAMPLES

     Example 1 Object Caching

     Consider the following data structure:

       struct foo {
          kmutex_t foo_lock;
          kcondvar_t foo_cv;
          struct bar *foo_barlist;
          int foo_refcnt;
          };

     Assume that a foo structure cannot be freed until there  are
     no outstanding references to it (foo_refcnt == 0) and all of
     its pending bar events (whatever they  are)  have  completed
     (foo_barlist == NULL). The life cycle of a dynamically allo-
     cated foo would be something like this:

       foo = kmem_alloc(sizeof (struct foo), KM_SLEEP);
       mutex_init(&foo->foo_lock, ...);
       cv_init(&foo->foo_cv, ...);
       foo->foo_refcnt = 0;
       foo->foo_barlist = NULL;
          use foo;
       ASSERT(foo->foo_barlist == NULL);
       ASSERT(foo->foo_refcnt == 0);
       cv_destroy(&foo->foo_cv);
       mutex_destroy(&foo->foo_lock);
       kmem_free(foo);

     Notice that between each use of a foo object  we  perform  a
     sequence  of  operations that constitutes nothing but expen-
     sive overhead. All of this  overhead  (that  is,  everything
     other  than use foo above) can be eliminated by object cach-
     ing.

       int
       foo_constructor(void *buf, void *arg, int tags)
       {
          struct foo *foo = buf;
          mutex_init(&foo->foo_lock, ...);
          cv_init(&foo->foo_cv, ...);
          foo->foo_refcnt = 0;
          foo->foo_barlist = NULL;
          return (0);
       }

       void
       foo_destructor(void *buf, void *arg)
       {
          struct foo *foo = buf;
          ASSERT(foo->foo_barlist == NULL);
          ASSERT(foo->foo_refcnt == 0);
          cv_destroy(&foo->foo_cv);
          mutex_destroy(&foo->foo_lock);
       }

       un = ddi_get_soft_state(foo_softc, instance);
       (void) snprintf(buf, KSTAT_STRLEN, "foo%d_cache",
              ddi_get_instance(dip));
       foo_cache = kmem_cache_create(buf,
              sizeof (struct foo), 0,
              foo_constructor, foo_destructor,
              NULL, un, 0);

     To allocate, use, and free a foo object:

       foo = kmem_cache_alloc(foo_cache, KM_SLEEP);
          use foo;
       kmem_cache_free(foo_cache, foo);

     This makes foo allocation fast, because the  allocator  will
     usually  do  nothing  more than fetch an already-constructed
     foo from the cache. foo_constructor and foo_destructor  will
     be  invoked  only  to  populate and drain the cache, respec-
     tively.


RETURN VALUES

     If successful, the constructor function must  return  0.  If
     KM_NOSLEEP  is  set  and  memory cannot be allocated without
     sleeping, the constructor must return -1.

     kmem_cache_create()  returns  a  pointer  to  the  allocated
     cache. If the name parameter contains non-alphanumeric char-
     acters, kmem_cache_create() returns NULL.

     If successful, kmem_cache_alloc() returns a pointer  to  the
     allocated  object. If KM_NOSLEEP is set and memory cannot be
     allocated without sleeping, kmem_cache_alloc() returns NULL.


ATTRIBUTES

     See attributes(5) for descriptions of the  following  attri-
     butes:

     ____________________________________________________________
    |       ATTRIBUTE TYPE        |       ATTRIBUTE VALUE       |
    |_____________________________|_____________________________|
    | Interface Stability         | Evolving                    |
    |_____________________________|_____________________________|


SEE ALSO

     condvar(9F), kmem_alloc(9F), mutex(9F), kstat(9S)

     The Slab Allocator: An Object-Caching Kernel Memory  Alloca-
     tor,  Bonwick,  J.;  USENIX Summer 1994 Technical Conference
     (1994).

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
1 目标检测的定义 目标检测(Object Detection)的任务是找出图像中所有感兴趣的目标(物体),确定它们的类别和位置,是计算机视觉领域的核心问题之一。由于各类物体有不同的外观、形状和姿态,加上成像时光照、遮挡等因素的干扰,目标检测一直是计算机视觉领域最具有挑战性的问题。 目标检测任务可分为两个关键的子任务,目标定位和目标分类。首先检测图像中目标的位置(目标定位),然后给出每个目标的具体类别(目标分类)。输出结果是一个边界框(称为Bounding-box,一般形式为(x1,y1,x2,y2),表示框的左上角坐标和右下角坐标),一个置信度分数(Confidence Score),表示边界框中是否包含检测对象的概率和各个类别的概率(首先得到类别概率,经过Softmax可得到类别标签)。 1.1 Two stage方法 目前主流的基于深度学习的目标检测算法主要分为两类:Two stage和One stage。Two stage方法将目标检测过程分为两个阶段。第一个阶段是 Region Proposal 生成阶段,主要用于生成潜在的目标候选框(Bounding-box proposals)。这个阶段通常使用卷积神经网络(CNN)从输入图像中提取特征,然后通过一些技巧(如选择性搜索)来生成候选框。第二个阶段是分类和位置精修阶段,将第一个阶段生成的候选框输入到另一个 CNN 中进行分类,并根据分类结果对候选框的位置进行微调。Two stage 方法的优点是准确度较高,缺点是速度相对较慢。 常见Tow stage目标检测算法有:R-CNN系列、SPPNet等。 1.2 One stage方法 One stage方法直接利用模型提取特征值,并利用这些特征值进行目标的分类和定位,不需要生成Region Proposal。这种方法的优点是速度快,因为省略了Region Proposal生成的过程。One stage方法的缺点是准确度相对较低,因为它没有对潜在的目标进行预先筛选。 常见的One stage目标检测算法有:YOLO系列、SSD系列和RetinaNet等。 2 常见名词解释 2.1 NMS(Non-Maximum Suppression) 目标检测模型一般会给出目标的多个预测边界框,对成百上千的预测边界框都进行调整肯定是不可行的,需要对这些结果先进行一个大体的挑选。NMS称为非极大值抑制,作用是从众多预测边界框中挑选出最具代表性的结果,这样可以加快算法效率,其主要流程如下: 设定一个置信度分数阈值,将置信度分数小于阈值的直接过滤掉 将剩下框的置信度分数从大到小排序,选中值最大的框 遍历其余的框,如果和当前框的重叠面积(IOU)大于设定的阈值(一般为0.7),就将框删除(超过设定阈值,认为两个框的里面的物体属于同一个类别) 从未处理的框中继续选一个置信度分数最大的,重复上述过程,直至所有框处理完毕 2.2 IoU(Intersection over Union) 定义了两个边界框的重叠度,当预测边界框和真实边界框差异很小时,或重叠度很大时,表示模型产生的预测边界框很准确。边界框A、B的IOU计算公式为: 2.3 mAP(mean Average Precision) mAP即均值平均精度,是评估目标检测模型效果的最重要指标,这个值介于0到1之间,且越大越好。mAP是AP(Average Precision)的平均值,那么首先需要了解AP的概念。想要了解AP的概念,还要首先了解目标检测中Precision和Recall的概念。 首先我们设置置信度阈值(Confidence Threshold)和IoU阈值(一般设置为0.5,也会衡量0.75以及0.9的mAP值): 当一个预测边界框被认为是True Positive(TP)时,需要同时满足下面三个条件: Confidence Score > Confidence Threshold 预测类别匹配真实值(Ground truth)的类别 预测边界框的IoU大于设定的IoU阈值 不满足条件2或条件3,则认为是False Positive(FP)。当对应同一个真值有多个预测结果时,只有最高置信度分数的预测结果被认为是True Positive,其余被认为是False Positive。 Precision和Recall的概念如下图所示: Precision表示TP与预测边界框数量的比值 Recall表示TP与真实边界框数量的比值 改变不同的置信度阈值,可以获得多组Precision和Recall,Recall放X轴,Precision放Y轴,可以画出一个Precision-Recall曲线,简称P-R
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值