linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Andrey Volkov <avolkov@varma-el.com>
To: jes@trained-monkey.org
Cc: Andrew Morton <akpm@osdl.org>,
	linux-kernel@vger.kernel.org, linuxppc-embedded@ozlabs.org
Subject: [RFC] genalloc != generic DEVICE memory allocator
Date: Wed, 21 Dec 2005 20:23:28 +0300	[thread overview]
Message-ID: <43A98F90.9010001@varma-el.com> (raw)

Hello Jes and all

I try to use your allocator (gen_pool_xxx), idea of which
is a cute nice thing. But current implementation of it is
inappropriate for a _device_ (aka onchip, like framebuffer) memory
allocation, by next reasons:

 1) Device memory is expensive resource by access time and/or size cost.
    So we couldn't use (usually) this memory for the free blocks lists.
 2) Device memory usually have special requirement of access to it
    (alignment/special insn). So we couldn't use part of allocated
    blocks for some control structures (this problem solved in your
    implementation, it's common remark)
 3) Obvious (IMHO) workflow of mem. allocator look like:
 	- at startup time, driver allocate some big
	  (almost) static mem. chunk(s) for a control/data structures.
        - during work of the device, driver allocate many small
	  mem. blocks with almost identical size.
    such behavior lead to degeneration of buddy method and
    transform it to the first/best fit method (with long seek
    by the free node list).
 4) The simple binary buddy method is far away from perfect for a device
    due to a big internal fragmentation. Especially for a
    network/mfd devices, for which, size of allocated data very
    often is not a power of 2.

I start to modify your code to satisfy above demands,
but firstly I wish to know your, or somebody else, opinion.

Especially I will very happy if somebody have and could
provide to all, some device specific memory usage statistics.

-- 
Regards
Andrey Volkov

             reply	other threads:[~2005-12-21 17:23 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-12-21 17:23 Andrey Volkov [this message]
2005-12-22  8:38 ` [RFC] genalloc != generic DEVICE memory allocator Pantelis Antoniou
2005-12-22 13:48   ` Andrey Volkov
2005-12-22 14:15     ` Pantelis Antoniou
2005-12-22 15:44       ` Andrey Volkov
2005-12-22 16:09         ` Pantelis Antoniou
     [not found] ` <43A9B2F1.8090402@246tNt.com>
2005-12-22 13:41   ` Andrey Volkov
2005-12-22 15:37 ` Jes Sorensen
2005-12-22 18:18   ` Andrey Volkov
2005-12-22 18:33     ` Pantelis Antoniou
2005-12-23  7:38       ` Andrey Volkov
2005-12-23  7:46         ` Pantelis Antoniou
2005-12-23 10:17           ` Andrey Volkov
2005-12-23 10:59     ` Jes Sorensen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=43A98F90.9010001@varma-el.com \
    --to=avolkov@varma-el.com \
    --cc=akpm@osdl.org \
    --cc=jes@trained-monkey.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-embedded@ozlabs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).