Re: Process-shared futexes on hugepages puts the kernel in aninfinite loop in 2.6.32.11; is this fixed now?

[Andrea Arcangeli]

On Mon, Apr 19, 2010 at 04:32:45PM +0100, Mel Gorman wrote:
> +#define HUGETLB_PRIVATE_MAPPING	(0x2e4 | PAGE_MAPPING_ANON)

Cute indeed.

BTW, just in case I tested this on transparent hugepage and it works
fine (it uses no cpu and can be killed with C^c). I had to hack it
like below to allocate the semaphore on hugepages without
khugepaged. I verified 1 hugepage is allocated (thanks to memory
compaction there's an huge excess of hugepages compared to what my
regular apps can eat ;). Furthermore I found gcc bypasses malloc so a
small patch to gcc should move it all into hugepages. Then maybe we
can build the kernel faster and definitely translate.o will build 8%
faster with the default khugepaged scan_sleep_millisecs settings
(waiting to be confirmed but I exclude bad surprises, whatever runs
fast with khugepaged has will run even faster without it if something,
or equal in the worst case).

Thanks,
Andrea

--- process-shared-sem-hugepage.c.orig	2010-04-19 17:43:47.278964888 +0200
+++ process-shared-sem-hugepage.c	2010-04-19 17:44:01.100032774 +0200
@@ -30,6 +30,7 @@ int main(void)
 
   g_thread_init(NULL);
   workers = g_new(GThread *, NWORKER); work_sem = g_new(sem_t, 1);
+  posix_memalign(&work_sem, 2*1024*1024, 2*1024*1024);
   result = sem_init(work_sem, TRUE, 0); g_assert(result == 0);
 
   for (i = 0; i < NWORKER; i++) {

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/