Re: [PATCH v2] alloc.h|c: migrate alloc_states to mem-pool

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

 



"阿德烈 via GitGitGadget"  <gitgitgadget@xxxxxxxxx> writes:

> From: ZheNing Hu <adlternative@xxxxxxxxx>
>
> "alloc_state" may have similar effects with "mem_pool".

What "similar effects" do you have in mind?  "mem_pool" may have
more than one "effects" to multiple things that are affected, but it
is unclear which effect that "mem_pool" exerts on what you are
referring to.

> Using the new memory pool API may be more beneficial
> to our memory management in the future.

Many things may or may not be "beneficial" in the future.  We do not
build things on a vague "hunch".

Are you seeking performance (e.g.  number of objects that can be
allocated per minute)?  Are you seeking better memory locality
(e.g. related objects are likely to be stored in the same page,
reducing number of page faults)?  Are you seeking reduced wasted
memory (e.g. custom allocator packs objects better than bog-standard
malloc(3))?  Are you seeking functionality (e.g. you have this and
that specific codepaths and usecase where you wish to be able to
release all the objects instantiated for a particular repository,
without having to go through the list of all objects, and use of
mempool is one way to allow us do so)?

It is not even clear in your problem description what kind of
benefit you are seeking, let alone how much quantitative improvement
you are getting with this change.





[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux