linux-kernel - Re: [PATCH/RFCv3 0/6] The Contiguous Memory Allocator framework

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 20 Aug 2010 15:57:51 +0900
From:	FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>
To:	m.nazarewicz@...sung.com
Cc:	fujita.tomonori@....ntt.co.jp, kyungmin.park@...sung.com,
	linux-mm@...ck.org, dwalker@...eaurora.org, linux@....linux.org.uk,
	corbet@....net, p.osciak@...sung.com,
	broonie@...nsource.wolfsonmicro.com, linux-kernel@...r.kernel.org,
	hvaibhav@...com, hverkuil@...all.nl, kgene.kim@...sung.com,
	zpfeffer@...eaurora.org, jaeryul.oh@...sung.com,
	linux-media@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	m.szyprowski@...sung.com
Subject: Re: [PATCH/RFCv3 0/6] The Contiguous Memory Allocator framework

On Fri, 20 Aug 2010 08:38:10 +0200
**UNKNOWN CHARSET** <m.nazarewicz@...sung.com> wrote:

> On Fri, 20 Aug 2010 05:12:50 +0200, FUJITA Tomonori <fujita.tomonori@....ntt.co.jp> wrote:
> >> 1. Integration on API level meaning that some kind of existing API is used
> >>     instead of new cma_*() calls.  CMA adds notion of devices and memory
> >>     types which is new to all the other APIs (coherent has notion of devices
> >>     but that's not enough).  This basically means that no existing API can be
> >>     used for CMA.  On the other hand, removing notion of devices and memory
> >>     types would defeat the whole purpose of CMA thus destroying the solution
> >>     that CMA provides.
> >
> > You can create something similar to the existing API for memory
> > allocator.
> 
> That may be tricky.  cma_alloc() takes four parameters each of which is
> required for CMA.  No other existing set of API uses all those arguments.
> This means, CMA needs it's own, somehow unique API.  I don't quite see
> how the APIs may be unified or "made similar".  Of course, I'm gladly
> accepting suggestions.

Have you even tried to search 'blk_kmalloc' on google? I wrote
"similar to the existing API', not "reuse the existing API".


> >> 2. Reuse of memory pools meaning that memory reserved by CMA can then be
> >>     used by other allocation mechanisms.  This is of course possible.  For
> >>     instance coherent could easily be implemented as a wrapper to CMA.
> >>     This is doable and can be done in the future after CMA gets more
> >>     recognition.
> >>
> >> 3. Reuse of algorithms meaning that allocation algorithms used by other
> >>     allocators will be used with CMA regions.  This is doable as well and
> >>     can be done in the future.
> >
> > Well, why can't we do the above before the inclusion?
> 
> Because it's quite a bit of work and instead of diverting my attention I'd
> prefer to make CMA as good as possible and then integrate it with other
> subsystems.  Also, adding the integration would change the patch from being
> 4k lines to being like 40k lines.

4k to 40k? I'm not sure. But If I see something like the following, I
suspect that there is a better way to integrate this into the existing
infrastructure.

mm/cma-best-fit.c                   |  407 +++++++++++++++
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/