CMA: test_pages_isolated failures in alloc_contig_range
Subsystems (3)
Hello,
I've run into a CMA-related issue while testing a DMA engine driver with dmatest on a Renesas R-Car ARM platform.
When allocating contiguous memory through CMA the kernel prints the following messages to the kernel log.
[ 99.770000] alloc_contig_range test_pages_isolated(6b843, 6b844) failed [ 124.220000] alloc_contig_range test_pages_isolated(6b843, 6b844) failed [ 127.550000] alloc_contig_range test_pages_isolated(6b845, 6b846) failed [ 132.850000] alloc_contig_range test_pages_isolated(6b845, 6b846) failed [ 151.390000] alloc_contig_range test_pages_isolated(6b843, 6b844) failed [ 166.490000] alloc_contig_range test_pages_isolated(6b843, 6b844) failed [ 181.450000] alloc_contig_range test_pages_isolated(6b845, 6b846) failed
I've stripped the dmatest module down as much as possible to remove any hardware dependencies and came up with the following implementation.
-----------------------------------------------------------------------------
/*
* CMA test module
*
* Copyright (C) 2014 Laurent Pinchart
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*/
#include <linux/delay.h>
#include <linux/dma-mapping.h>
#include <linux/freezer.h>
#include <linux/kthread.h>
#include <linux/module.h>
#include <linux/moduleparam.h>
#include <linux/slab.h>
#include <linux/wait.h>
static unsigned int num_threads = 4; module_param(num_threads, uint, S_IRUGO | S_IWUSR);
static unsigned int iterations = 100000; module_param(iterations, uint, S_IRUGO | S_IWUSR);
struct cma_test_thread {
struct list_head node;
struct task_struct *task;
bool done;
};static DECLARE_WAIT_QUEUE_HEAD(thread_wait);
static LIST_HEAD(threads);
static int cma_test_thread(void *data)
{
struct cma_test_thread *thread = data;
unsigned int i = 0;
set_freezable();
while (!kthread_should_stop() && i < iterations) {
dma_addr_t dma;
void *mem;
mem = dma_alloc_coherent(NULL, 32, &dma, GFP_KERNEL);
usleep_range(1000, 2000);
if (mem)
dma_free_coherent(NULL, 32, mem, dma);
else
printk(KERN_INFO "allocation error @%u\n", i);
++i;
}
thread->done = true;
wake_up(&thread_wait);
return 0;
}static bool cma_test_threads_done(void)
{
struct cma_test_thread *thread;
list_for_each_entry(thread, &threads, node) {
if (!thread->done)
return false;
}
return true;
}static int cma_test_init(void)
{
struct cma_test_thread *thread, *_thread;
unsigned int i;
for (i = 0; i < num_threads; ++i) {
thread = kzalloc(sizeof(*thread), GFP_KERNEL);
if (!thread) {
pr_warn("No memory for thread %u\n", i);
break;
}
thread->task = kthread_create(cma_test_thread, thread,
"cmatest-%u", i);
if (IS_ERR(thread->task)) {
pr_warn("Failed to create thread %u\n", i);
kfree(thread);
break;
}
get_task_struct(thread->task);
list_add_tail(&thread->node, &threads);
wake_up_process(thread->task);
}
wait_event(thread_wait, cma_test_threads_done());
list_for_each_entry_safe(thread, _thread, &threads, node) {
kthread_stop(thread->task);
put_task_struct(thread->task);
list_del(&thread->node);
kfree(thread);
}
return 0;
}module_init(cma_test_init);
static void cma_test_exit(void)
{
}module_exit(cma_test_exit);
MODULE_AUTHOR("Laurent Pinchart");MODULE_LICENSE("GPL v2");
-----------------------------------------------------------------------------
Loading the module will start 4 threads that will allocate and free DMA coherent memory in a tight loop and eventually produce the error. It seems like the probability of occurrence grows with the number of threads, which could indicate a race condition.
The tests have been run on 3.18-rc1, but previous tests on 3.16 did exhibit the same behaviour.
I'm not that familiar with the CMA internals, help would be appreciated to debug the problem.
Signature · 9 lines
Regards, Laurent Pinchart -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Quoted 19 lines · Laurent Pinchart
Hello,
I've run into a CMA-related issue while testing a DMA engine driver with dmatest on a Renesas R-Car ARM platform.
When allocating contiguous memory through CMA the kernel prints the following messages to the kernel log.
[ 99.770000] alloc_contig_range test_pages_isolated(6b843, 6b844) failed [ 124.220000] alloc_contig_range test_pages_isolated(6b843, 6b844) failed [ 127.550000] alloc_contig_range test_pages_isolated(6b845, 6b846) failed [ 132.850000] alloc_contig_range test_pages_isolated(6b845, 6b846) failed [ 151.390000] alloc_contig_range test_pages_isolated(6b843, 6b844) failed [ 166.490000] alloc_contig_range test_pages_isolated(6b843, 6b844) failed [ 181.450000] alloc_contig_range test_pages_isolated(6b845, 6b846) failedI've stripped the dmatest module down as much as possible to remove any hardware dependencies and came up with the following implementation.
...
Quoted 6 lines
Loading the module will start 4 threads that will allocate and free DMA coherent memory in a tight loop and eventually produce the error. It seems like the probability of occurrence grows with the number of threads, which could indicate a race condition.
Quoted 6 lines
The tests have been run on 3.18-rc1, but previous tests on 3.16 did exhibit the same behaviour.
I'm not that familiar with the CMA internals, help would be appreciated to debug the problem.
Are you actually seeing allocation failures or is it just the messages? The messages themselves may be harmless if the allocation is succeeding. It's an indication that the particular range could not be isolated and therefore another range should be used for the CMA allocation. Joonsoo Kim had a patch series[1] that was designed to correct some problems with isolation and from my testing it helps fix some CMA related errors. You might try picking that up to see if it helps.
Thanks,
Laura
[1] https://lkml.org/lkml/2014/10/23/90
Signature · 3 lines
Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
Hi Laura,
Quoted 27 lines · On Monday 27 October 2014 13:38:19 Laura Abbott wrote:
Quoted 18 lines · Laurent Pinchart
Hello,
I've run into a CMA-related issue while testing a DMA engine driver with dmatest on a Renesas R-Car ARM platform.
When allocating contiguous memory through CMA the kernel prints the following messages to the kernel log.
[ 99.770000] alloc_contig_range test_pages_isolated(6b843, 6b844) failed [ 124.220000] alloc_contig_range test_pages_isolated(6b843, 6b844) failed [ 127.550000] alloc_contig_range test_pages_isolated(6b845, 6b846) failed [ 132.850000] alloc_contig_range test_pages_isolated(6b845, 6b846) failed [ 151.390000] alloc_contig_range test_pages_isolated(6b843, 6b844) failed [ 166.490000] alloc_contig_range test_pages_isolated(6b843, 6b844) failed [ 181.450000] alloc_contig_range test_pages_isolated(6b845, 6b846) failedI've stripped the dmatest module down as much as possible to remove any hardware dependencies and came up with the following implementation.
...
Quoted 5 lines
Loading the module will start 4 threads that will allocate and free DMA coherent memory in a tight loop and eventually produce the error. It seems like the probability of occurrence grows with the number of threads, which could indicate a race condition.
Quoted 7 lines
Quoted 5 lines
The tests have been run on 3.18-rc1, but previous tests on 3.16 did exhibit the same behaviour.
I'm not that familiar with the CMA internals, help would be appreciated to debug the problem.
Are you actually seeing allocation failures or is it just the messages?
It's just the messages, I haven't noticed allocation failures.
Quoted 11 lines
The messages themselves may be harmless if the allocation is succeeding. It's an indication that the particular range could not be isolated and therefore another range should be used for the CMA allocation. Joonsoo Kim had a patch series[1] that was designed to correct some problems with isolation and from my testing it helps fix some CMA related errors. You might try picking that up to see if it helps.
Thanks,
Laura
I've tested the patches but they don't seem to have any influence on the isolation test failures.
Signature · 9 lines
Regards, Laurent Pinchart -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Quoted 16 lines · Laurent Pinchart
Hello,
I've run into a CMA-related issue while testing a DMA engine driver with dmatest on a Renesas R-Car ARM platform.
When allocating contiguous memory through CMA the kernel prints the following messages to the kernel log.
[ 99.770000] alloc_contig_range test_pages_isolated(6b843, 6b844) failed [ 124.220000] alloc_contig_range test_pages_isolated(6b843, 6b844) failed [ 127.550000] alloc_contig_range test_pages_isolated(6b845, 6b846) failed [ 132.850000] alloc_contig_range test_pages_isolated(6b845, 6b846) failed [ 151.390000] alloc_contig_range test_pages_isolated(6b843, 6b844) failed [ 166.490000] alloc_contig_range test_pages_isolated(6b843, 6b844) failed [ 181.450000] alloc_contig_range test_pages_isolated(6b845, 6b846) failed
Quoted 2 lines
I've stripped the dmatest module down as much as possible to remove any hardware dependencies and came up with the following implementation.
Like Laura wrote, the message is not (should not be) a problem in itself:
mm/page_alloc.c:
int alloc_contig_range(unsigned long start, unsigned long end,
unsigned migratetype)
{
[…]
/* Make sure the range is really isolated. */
if (test_pages_isolated(outer_start, end, false)) {
pr_warn("alloc_contig_range test_pages_isolated(%lx, %lx) failed\n",
outer_start, end);
ret = -EBUSY;
goto done;
}
[…]
done:
undo_isolate_page_range(pfn_max_align_down(start),
pfn_max_align_up(end), migratetype);
return ret;
}mm/cma.c:
struct page *cma_alloc(struct cma *cma, int count, unsigned int align)
{
[…]
for (;;) {
bitmap_no = bitmap_find_next_zero_area(cma->bitmap,
bitmap_maxno, start, bitmap_count, mask);
if (bitmap_no >= bitmap_maxno)
break;
bitmap_set(cma->bitmap, bitmap_no, bitmap_count);
pfn = cma->base_pfn + (bitmap_no << cma->order_per_bit);
ret = alloc_contig_range(pfn, pfn + count, MIGRATE_CMA);
if (ret = 0) {
page = pfn_to_page(pfn);
break;
}
cma_clear_bitmap(cma, pfn, count);
if (ret != -EBUSY)
break;
pr_debug("%s(): memory range at %p is busy, retrying\n",
__func__, pfn_to_page(pfn));
/* try again with a bit different memory target */
start = bitmap_no + mask + 1;
}
[…]
}So as you can see cma_alloc will try another part of the cma region if test_pages_isolated fails.
Obviously, if CMA region is fragmented or there's enough space for only one allocation of required size isolation failures will cause allocation failures, so it's best to avoid them, but they are not always avoidable.
To debug you would probably want to add more debug information about the page (i.e. data from struct page) that failed isolation after the pr_warn in alloc_contig_range.
Signature · 4 lines
Best regards, _ _ .o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o ..o | Computer Science, Michał “mina86” Nazarewicz (o o) ooo +--<[email protected]>--<xmpp:[email protected]>--ooO--(_)--Ooo--
[ +cc Andrew Morton ]
Quoted 22 lines · Michal Nazarewicz
Quoted 16 lines · Laurent Pinchart
Hello,
I've run into a CMA-related issue while testing a DMA engine driver with dmatest on a Renesas R-Car ARM platform.
When allocating contiguous memory through CMA the kernel prints the following messages to the kernel log.
[ 99.770000] alloc_contig_range test_pages_isolated(6b843, 6b844) failed [ 124.220000] alloc_contig_range test_pages_isolated(6b843, 6b844) failed [ 127.550000] alloc_contig_range test_pages_isolated(6b845, 6b846) failed [ 132.850000] alloc_contig_range test_pages_isolated(6b845, 6b846) failed [ 151.390000] alloc_contig_range test_pages_isolated(6b843, 6b844) failed [ 166.490000] alloc_contig_range test_pages_isolated(6b843, 6b844) failed [ 181.450000] alloc_contig_range test_pages_isolated(6b845, 6b846) failedQuoted 2 lines
I've stripped the dmatest module down as much as possible to remove any hardware dependencies and came up with the following implementation.
Like Laura wrote, the message is not (should not be) a problem in itself:
[...]
Quoted 10 lines
So as you can see
cma_allocwill try another part of the cma region iftest_pages_isolatedfails.Obviously, if CMA region is fragmented or there's enough space for only one allocation of required size isolation failures will cause allocation failures, so it's best to avoid them, but they are not always avoidable.
To debug you would probably want to add more debug information about the page (i.e. data from struct page) that failed isolation after the
pr_warninalloc_contig_range.
If the message does not indicate an actual problem, then its printk level is too high. These messages have been reported when using 3.16+ distro kernels.
Regards,
Peter Hurley
Quoted 16 lines · Michal Nazarewicz
Quoted 2 lines
Like Laura wrote, the message is not (should not be) a problem in itself:
[...]
Quoted 10 lines
So as you can see
cma_allocwill try another part of the cma region iftest_pages_isolatedfails.Obviously, if CMA region is fragmented or there's enough space for only one allocation of required size isolation failures will cause allocation failures, so it's best to avoid them, but they are not always avoidable.
To debug you would probably want to add more debug information about the page (i.e. data from struct page) that failed isolation after the
pr_warninalloc_contig_range.
Quoted 2 lines · Peter Hurley
If the message does not indicate an actual problem, then its printk level is too high. These messages have been reported when using 3.16+ distro kernels.
I think it could be argued both ways. The condition is not an error, since in many cases cma_alloc will be able to continue, but it *is* an undesired state. As such it's not an error but feels to me a bit more then just information, hence a warning. I don't care either way, though.
Signature · 4 lines
Best regards, _ _ .o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o ..o | Computer Science, Michał “mina86” Nazarewicz (o o) ooo +--<[email protected]>--<xmpp:[email protected]>--ooO--(_)--Ooo--
Quoted 17 lines · Michal Nazarewicz
Quoted 9 lines · Michal Nazarewicz
Quoted 2 lines
Like Laura wrote, the message is not (should not be) a problem in itself:
[...]
Quoted 3 lines
So as you can see
cma_allocwill try another part of the cma region iftest_pages_isolatedfails.Quoted 7 lines
Quoted 7 lines
Obviously, if CMA region is fragmented or there's enough space for only one allocation of required size isolation failures will cause allocation failures, so it's best to avoid them, but they are not always avoidable.
To debug you would probably want to add more debug information about the page (i.e. data from struct page) that failed isolation after the
pr_warninalloc_contig_range.
Quoted 8 lines
Quoted 2 lines · Peter Hurley
If the message does not indicate an actual problem, then its printk level is too high. These messages have been reported when using 3.16+ distro kernels.
I think it could be argued both ways. The condition is not an error, since in many cases
cma_allocwill be able to continue, but it *is* an undesired state. As such it's not an error but feels to me a bit more then just information, hence a warning. I don't care either way, though.
This "undesired state" is trivially reproducible on 3.16.y on the x86 arch; a smattering of these will show up just building a distro kernel.
Hello,
Quoted 27 lines · On Tuesday 28 October 2014 09:48:26 Peter Hurley wrote:
[ +cc Andrew Morton ]
Quoted 24 lines · Michal Nazarewicz
Quoted 23 lines · Laurent Pinchart
Hello,
I've run into a CMA-related issue while testing a DMA engine driver with dmatest on a Renesas R-Car ARM platform.
When allocating contiguous memory through CMA the kernel prints the following messages to the kernel log.
[ 99.770000] alloc_contig_range test_pages_isolated(6b843, 6b844) failed [ 124.220000] alloc_contig_range test_pages_isolated(6b843, 6b844) failed [ 127.550000] alloc_contig_range test_pages_isolated(6b845, 6b846) failed [ 132.850000] alloc_contig_range test_pages_isolated(6b845, 6b846) failed [ 151.390000] alloc_contig_range test_pages_isolated(6b843, 6b844) failed [ 166.490000] alloc_contig_range test_pages_isolated(6b843, 6b844) failed [ 181.450000] alloc_contig_range test_pages_isolated(6b845, 6b846)failed
Quoted 18 lines
Quoted 5 lines
Quoted 2 lines
I've stripped the dmatest module down as much as possible to remove any hardware dependencies and came up with the following implementation.
Like Laura wrote, the message is not (should not be) a problem in itself:
[...]
Quoted 10 lines
So as you can see
cma_allocwill try another part of the cma region iftest_pages_isolatedfails.Obviously, if CMA region is fragmented or there's enough space for only one allocation of required size isolation failures will cause allocation failures, so it's best to avoid them, but they are not always avoidable.
To debug you would probably want to add more debug information about the page (i.e. data from struct page) that failed isolation after the
pr_warninalloc_contig_range.
[ 94.730000] __test_page_isolated_in_pageblock: failed at pfn 6b845: buddy 0 count 0 migratetype 4 poison 0 [ 94.740000] alloc_contig_range test_pages_isolated(6b845, 6b846) failed (-16) [ 202.140000] __test_page_isolated_in_pageblock: failed at pfn 6b843: buddy 0 count 0 migratetype 4 poison 0 [ 202.150000] alloc_contig_range test_pages_isolated(6b843, 6b844) failed
(-16)
(4 is MIGRATE_CMA)
Quoted 2 lines
If the message does not indicate an actual problem, then its printk level is too high. These messages have been reported when using 3.16+ distro kernels.
The messages got me worried, and if there's nothing to worry about, that's bad :-)
Signature · 3 lines
Regards, Laurent Pinchart
PATCH 1/1 mm: alloc_contig_range: demote pages busy message from warn to info
In reply to Laurent PinchartHaving test_pages_isolated failure message as a warning confuses users into thinking that it is more serious than it really is. In reality, if called via CMA, allocation will be retried so a single test_pages_isolated failure does not prevent allocation from succeeding.
Demote the warning message to an info message and reformat it such that the text “failed” does not appear and instead a less worrying “PFNS busy” is used.
--- mm/page_alloc.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-)
mm/page_alloc.c +2 -3
@@ -6431,13 +6431,12 @@ int alloc_contig_range(unsigned long start, unsigned long end,/* Make sure the range is really isolated. */ if (test_pages_isolated (outer_start, end, false)) { -pr_warn ("alloc_contig_range test_pages_isolated(%lx, %lx) failed\n" , - outer_start, end); +pr_info ("%s: [%lx, %lx) PFNs busy\n" , + __func__, outer_start, end); ret = -EBUSY ; goto done; } -/* Grab isolated pages from freelists. */ outer_end =isolate_freepages_range (&cc, outer_start, end);if (!outer_end) {
Signature · 7 lines
2.1.0.rc2.206.gedb03e5 -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Re: [PATCH] mm: alloc_contig_range: demote pages busy message from warn to info
Hello,
Quoted 9 lines · Michal Nazarewicz
Having
test_pages_isolatedfailure message as a warning confuses users into thinking that it is more serious than it really is. In reality, if called via CMA, allocation will be retried so a singletest_pages_isolatedfailure does not prevent allocation from succeeding.Demote the warning message to an info message and reformat it such that the text “failed” does not appear and instead a less worrying “PFNS busy” is used.
What do you expect from this message? Please describe it so that we can review below message helps your goal.
Quoted 34 lines
Signed-off-by Michal Nazarewicz <[email protected]>--- mm/page_alloc.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-)mm/page_alloc.c +2
-3@@ -6431,13 +6431,12 @@ int alloc_contig_range(unsigned long start, unsigned long end,/* Make sure the range is really isolated. */ if (test_pages_isolated (outer_start, end, false)) { -pr_warn ("alloc_contig_range test_pages_isolated(%lx, %lx) failed\n" , - outer_start, end); +pr_info ("%s: [%lx, %lx) PFNs busy\n" , + __func__, outer_start, end); ret = -EBUSY ; goto done; } -/* Grab isolated pages from freelists. */ outer_end =isolate_freepages_range (&cc, outer_start, end);if (!outer_end) {Signature · 7 lines
2.1.0.rc2.206.gedb03e5 -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Signature · 2 lines
Kind regards, Minchan Kim
Re: [PATCH] mm: alloc_contig_range: demote pages busy message from warn to info
Quoted 9 lines · Minchan Kim
Hello,
Quoted 6 lines · Michal Nazarewicz
Having
test_pages_isolatedfailure message as a warning confuses users into thinking that it is more serious than it really is. In reality, if called via CMA, allocation will be retried so a singletest_pages_isolatedfailure does not prevent allocation from succeeding.
Quoted 6 lines
Quoted 3 lines
Demote the warning message to an info message and reformat it such that the text a??faileda?? does not appear and instead a less worrying a??PFNS busya?? is used.
What do you expect from this message? Please describe it so that we can review below message helps your goal.
I expect this message to not show up in logs unless there is a real problem.
This message is trivially reproducible on a 10GB x86 machine on 3.16.y kernels configured with CONFIG_DMA_CMA.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Re: [PATCH] mm: alloc_contig_range: demote pages busy message from warn to info
Quoted 10 lines · Peter Hurley
Quoted 9 lines · Minchan Kim
Hello,
Quoted 6 lines · Michal Nazarewicz
Having
test_pages_isolatedfailure message as a warning confuses users into thinking that it is more serious than it really is. In reality, if called via CMA, allocation will be retried so a singletest_pages_isolatedfailure does not prevent allocation from succeeding.
Quoted 8 lines
Quoted 6 lines
Quoted 3 lines
Demote the warning message to an info message and reformat it such that the text “failed” does not appear and instead a less worrying “PFNS busy” is used.
What do you expect from this message? Please describe it so that we can review below message helps your goal.
I expect this message to not show up in logs unless there is a real problem.
So frankly I don't care. Feel free to send a patch removing the message all together. I'll be happy to ack it.
Signature · 10 lines
Best regards, _ _ .o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o ..o | Computer Science, Michał “mina86” Nazarewicz (o o) ooo +--<[email protected]>--<xmpp:[email protected]>--ooO--(_)--Ooo-- -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Re: [PATCH] mm: alloc_contig_range: demote pages busy message from warn to info
Quoted 15 lines · Michal Nazarewicz
Quoted 14 lines · Peter Hurley
Quoted 13 lines · Minchan Kim
Hello,
Quoted 9 lines · Michal Nazarewicz
Having
test_pages_isolatedfailure message as a warning confuses users into thinking that it is more serious than it really is. In reality, if called via CMA, allocation will be retried so a singletest_pages_isolatedfailure does not prevent allocation from succeeding.Demote the warning message to an info message and reformat it such that the text a??faileda?? does not appear and instead a less worrying a??PFNS busya?? is used.
Quoted 7 lines
Quoted 4 lines
Quoted 2 lines
What do you expect from this message? Please describe it so that we can review below message helps your goal.
I expect this message to not show up in logs unless there is a real problem.
So frankly I don't care. Feel free to send a patch removing the message all together. I'll be happy to ack it.
I'd rather just remove CMA allocation from the iommu providers on x86.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>