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
| ||
|
Date: Wed, 24 Nov 2010 09:36:53 +0900 From: KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com> To: Michał Nazarewicz <m.nazarewicz@...sung.com> Cc: Andrew Morton <akpm@...ux-foundation.org>, "linux-mm@...ck.org" <linux-mm@...ck.org>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, minchan.kim@...il.com, Bob Liu <lliubbo@...il.com>, fujita.tomonori@....ntt.co.jp, pawel@...iak.com, andi.kleen@...el.com, felipe.contreras@...il.com, "kosaki.motohiro@...fujitsu.com" <kosaki.motohiro@...fujitsu.com>, Marek Szyprowski <m.szyprowski@...sung.com> Subject: Re: [PATCH 0/4] big chunk memory allocator v4 On Tue, 23 Nov 2010 16:46:03 +0100 Michał Nazarewicz <m.nazarewicz@...sung.com> wrote: > A few things than: > > 1. As Felipe mentioned, on ARM it is often desired to have the memory > mapped as non-cacheable, which most often mean that the memory never > reaches the page allocator. This means, that alloc_contig_pages() > would not be suitable for cases where one needs such memory. > > Or could this be overcome by adding the memory back as highmem? But > then, it would force to compile in highmem support even if platform > does not really need it. > > 2. Device drivers should not by themselves know what ranges of memory to > allocate memory from. Moreover, some device drivers could require > allocation different buffers from different ranges. As such, this > would require some management code on top of alloc_contig_pages(). > > 3. When posting hwmem, Johan Mossberg mentioned that he'd like to see > notion of "pinning" chunks (so that not-pinned chunks can be moved > around when hardware does not use them to defragment memory). This > would again require some management code on top of > alloc_contig_pages(). > > 4. I might be mistaken here, but the way I understand ZONE_MOVABLE work > is that it is cut of from the end of memory. Or am I talking nonsense? > My concern is that at least one chip I'm working with requires > allocations from different memory banks which would basically mean that > there would have to be two movable zones, ie: > > +-------------------+-------------------+ > | Memory Bank #1 | Memory Bank #2 | > +---------+---------+---------+---------+ > | normal | movable | normal | movable | > +---------+---------+---------+---------+ > yes. > So even though I'm personally somehow drawn by alloc_contig_pages()'s > simplicity (compared to CMA at least), those quick thoughts make me think > that alloc_contig_pages() would work rather as a backend (as Kamezawa > mentioned) for some, maybe even tiny but still present, management code > which would handle "marking memory fragments as ZONE_MOVABLE" (whatever > that would involve) and deciding which memory ranges drivers can allocate > from. > > I'm also wondering whether alloc_contig_pages()'s first-fit is suitable but > that probably cannot be judged without some benchmarks. > I'll continue to update patches, you can freely reuse my code and integrate this set to yours. I works for this firstly for EMBEDED but I want this to be a _generic_ function for gerenal purpose architecture. There may be guys who want 1G page on a host with tons of free memory. Thanks, -Kame -- 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/
Powered by blists - more mailing lists