Thread: [SSI-devel] OpenSSI preview on Debian Lenny
Brought to you by:
brucewalker,
rogertsang
From: John H. <john@Calva.COM> - 2010-02-18 13:56:03
|
My preview 2.6.12 and 2.6.14 kernels are now up to date with current CVS (as of 17/2/2010), including Roger's latest checkins and the x86_64 port. The kernels are available for i386 and x86_64. i386 passes all regression tests and works for me. x86_64 has some bugs: 1764324-badness-in-sk_del_node_init ...FAILED 1766275-reop_export_path ...FAILED can't run i386 programs migrating a process with an open tty gets infinite loop of EINTR on tty ioctls. |
From: John H. <john@Calva.COM> - 2010-02-19 11:17:15
|
John Hughes wrote: > My preview 2.6.12 and 2.6.14 kernels are now up to date with current CVS > (as of 17/2/2010), including Roger's latest checkins and the x86_64 port. > Ok, I've withdrawn the 2.6.14 kernel on x86_64 'cos it doesn't work - crashes in login. The 2.6.12 kernel is working somewhat. > [...] > > x86_64 has some bugs: > > [...] > > can't run i386 programs > Because I forgot to turn on ia32 compatability. New kernel coming soon. |
From: John H. <john@Calva.COM> - 2010-02-19 15:25:21
|
John Hughes wrote: > John Hughes wrote: > >> My preview 2.6.12 and 2.6.14 kernels are now up to date with current CVS >> (as of 17/2/2010), including Roger's latest checkins and the x86_64 port. >> >> x86_64 has some bugs: >> >> [...] >> >> ia32 compatability turned back on. migration doesn't seem to work at the moment. |
From: John H. <john@Calva.COM> - 2010-02-21 16:51:53
|
John Hughes wrote: > John Hughes wrote: > >> John Hughes wrote: >> >> >>> My preview 2.6.12 and 2.6.14 kernels are now up to date with current CVS >>> (as of 17/2/2010), including Roger's latest checkins and the x86_64 port. >>> >>> x86_64 has some bugs: >>> >>> > migration doesn't seem to work at the moment. > Fixed crash in case where a binfmt didn't have a name. Now dying in as_untranscribe -> as_do_pg -> pte_alloc_map -> BANG! general protection fault: 0000 [1] SMP Entering kdb (current=0xffff81001d6da3b0, pid 132848) on processor 0 Oops: <NULL> due to oops @ 0xffffffff80179522 r15 = 0x0000000000000000 r14 = 0xffff81001fbb8568 r13 = 0xffff81001d77a3c8 r12 = 0xffff81001fbb8500 rbp = 0xffff81001d779200 rbx = 0x0000000000600000 r11 = 0xffff81001dd3c000 r10 = 0xffff81001f8ce000 r9 = 0x0000000000000010 r8 = 0xffff81001d77a318 rax = 0x0000ff5300000018 rcx = 0x03fffffffffff000 rdx = 0x0000000000600000 rsi = 0x0000805300000018 rdi = 0xffff81001fbb8500 orig_rax = 0xffffffffffffffff rip = 0xffffffff80179522 cs = 0x0000000000000010 eflags = 0x0000000000010296 rsp = 0xffff81001d523c10 ss = 0xffff81001d522000 ®s = 0xffff81001d523b78 [0]kdb> bt Stack traceback for pid 132848 0xffff81001d6da3b0 132848 2 1 0 R 0xffff81001d6da670 *a.out RSP RIP Function (args) 0xffff81001d523c10 0xffffffff80179522 pte_alloc_map+0x22 (0x0, 0x0, 0xffff81001fbb8550, 0x0, 0x1) 0xffff81001d523c58 0xffffffff80270579 as_untranscribe+0x5e9 (0x0, 0xffff81001fbb8500, 0x0, 0xffff81001cd99140, 0x4) 0xffff81001d523d08 0xffffffff8026c259 full_data_unload_msg+0x89 (0xffff81001d6da580, 0xffffffff8013ca92, 0x0, 0x0, 0xffff81001d6da3b0) 0xffff81001d523d38 0xffffffff8026cbbb migrate_pproc_unload_msg+0x15b (0xffff81001d523f58, 0x7fffffd34750, 0xffff81001fbcf580, 0xffffffff80146e77, 0x300000000) 0xffff81001d523d98 0xffffffff8026aab3 migrate_server+0xf3 (0xffff81001d77acb8, 0xffff81001d6da3b0, 0xffff81001d523f58, 0xffffffff804a711d, 0x14) 0xffff81001d523e68 0xffffffff80269a73 migrate_server_setup+0x73 0xffff81001d523f58 0xffffffff80110a38 child_rip+0x8 [0]kdb> |
From: John H. <john@Calva.COM> - 2010-02-22 15:10:31
|
adp: mm = ffff81001d3e6a40 adp: pmd = 0000805300000018 adp: apid = ffff81001f69d000 adp: api_addr = 0000000000600000 general protection fault: 0000 [1] SMP Entering kdb (current=0xffff81001d5e7800, pid 132740) on processor 0 Oops: <NULL> due to oops @ 0xffffffff80179522 r15 = 0x0000000000000000 r14 = 0xffff810000000000 r13 = 0xffff81001d2b5108 r12 = 0xffff81001d3e6a40 rbp = 0xffff81001f69d000 rbx = 0x0000000000600000 r11 = 0x0000000000000000 r10 = 0x0000000000000000 r9 = 0x0000000000000000 r8 = 0x0000000000000720 rax = 0x0000000000000027 rcx = 0x0000000000000010 rdx = 0x0000000000600000 rsi = 0x0000805300000018 rdi = 0xffff81001d3e6a40 orig_rax = 0xffffffffffffffff rip = 0xffffffff80179522 cs = 0x0000000000000010 eflags = 0x0000000000010296 rsp = 0xffff81001dd1dc00 ss = 0xffff81001dd1c000 ®s = 0xffff81001dd1db68 [0]kdb> [0]kdb> id pte_alloc_map 0xffffffff80179500 pte_alloc_map: sub $0x28,%rsp 0xffffffff80179504 pte_alloc_map+0x4: mov %rbx,(%rsp) 0xffffffff80179508 pte_alloc_map+0x8: mov %rbp,0x8(%rsp) 0xffffffff8017950d pte_alloc_map+0xd: mov %rdx,%rbx 0xffffffff80179510 pte_alloc_map+0x10: mov %r12,0x10(%rsp) 0xffffffff80179515 pte_alloc_map+0x15: mov %r13,0x18(%rsp) 0xffffffff8017951a pte_alloc_map+0x1a: mov %rdi,%r12 0xffffffff8017951d pte_alloc_map+0x1d: mov %r14,0x20(%rsp) 0xffffffff80179522 pte_alloc_map+0x22: mov (%rsi),%rdx Or, to put it another way: 0000000000000850 <pte_alloc_map>: pte_t fastcall *pte_alloc_map(struct mm_struct *mm, pmd_t *pmd, unsigned long address) { 850: 48 83 ec 28 sub $0x28,%rsp 854: 48 89 1c 24 mov %rbx,(%rsp) 858: 48 89 6c 24 08 mov %rbp,0x8(%rsp) 85d: 48 89 d3 mov %rdx,%rbx 860: 4c 89 64 24 10 mov %r12,0x10(%rsp) 865: 4c 89 6c 24 18 mov %r13,0x18(%rsp) 86a: 49 89 fc mov %rdi,%r12 86d: 4c 89 74 24 20 mov %r14,0x20(%rsp) if (!pmd_present(*pmd)) { 872: 48 8b 16 mov (%rsi),%rdx } 875: 48 89 f5 mov %rsi,%rbp if (!pmd_present(*pmd)) { 878: f6 c2 01 test $0x1,%dl 87b: 0f 85 c0 00 00 00 jne 941 <pte_alloc_map+0xf1> Going "BANG" on the pmd_present(*pmd) What's at (%rsi) (aka *pmd)? md 0x0000805300000018 kdb_getarea: Bad address 0x805300000018 Sad, that seems not to be a good address. Wild, it looks like pmd_alloc has given us a bad address?!!@# if (!(pmd = pmd_alloc(mm, pud, apip->api_addr))) { error = -EAGAIN; goto out_unlock_spin; } if (!(pte = pte_alloc_map(mm, pmd, apip->api_addr))) { error = -EAGAIN; goto out_unlock_spin; } Is it normal that api_addr is zero? Does address zero exist? |
From: John H. <john@Calva.COM> - 2010-02-22 22:06:26
|
John Hughes wrote: > adp: api_addr = 0000000000600000 > > Is it normal that api_addr is zero? Does address zero exist? > Argh. It isn't zero, it's 0x600000, which is perfectly reasonable. What on earth is going wrong. |
From: John H. <john@Calva.COM> - 2010-04-15 20:34:43
|
John Hughes wrote: > John Hughes wrote: > >> John Hughes wrote: >> >> >> migration doesn't seem to work at the moment. >> >> > Fixed crash in case where a binfmt didn't have a name. > > Now dying in as_untranscribe -> as_do_pg -> pte_alloc_map -> BANG! > With the current x86_64 kernel it no longer crashes. :-) Still doesn't work though. :-( Will try some debugging this weekend. $ onnode 1 sh -c "cluster -v; clusternode_num; echo 2 >/proc/self/goto; clusternode_num" 1: UP 2: UP 1 1 Amusingly nothing other than "rexec" shows up in /proc/cluster/loadlog. |
From: Roger T. <rog...@gm...> - 2010-04-17 20:29:33
|
Further it appears as_do_pg() is just a dupe of Linux install_arg_page(). To avoid this duplication it is better to modify as_do_pg() to call something like ssi_install_arg_page() which is install_arg_page() without force_sig() in error path. On Sat, Apr 17, 2010 at 2:36 PM, John Hughes <jo...@ca...> wrote: > John Hughes wrote: > > John Hughes wrote: >> >>> >>> pud = pud_offset(pgd, apip->api_addr); >>> >> It seems than when we get here "pgd_none (pgd)" is true, so maybe we >> should be doing a pud_alloc instead of just "pud = pud_offset(...)". >> >> But it doesn't seem to work, that just makes us hang. >> > Because I screwed up. > > Yes, we should be doing pud_alloc, not just pud_offset. > > This patch makes migration work. > > Well, almost. The migrated process seems not to be able to access its > terminal. > > > > > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > ssic-linux-devel mailing list > ssi...@li... > https://lists.sourceforge.net/lists/listinfo/ssic-linux-devel > > |
From: Roger T. <rog...@gm...> - 2010-04-17 22:03:54
|
Also support for 4-level page table is not yet there in vproc/as_xscribe.c. It currently skips the PUD table. That is probably why process migration isn't working properly in x86_64. I'm adding code to traverse the PUD table as we speak. On Sat, Apr 17, 2010 at 4:29 PM, Roger Tsang <rog...@gm...> wrote: > Further it appears as_do_pg() is just a dupe of Linux install_arg_page(). > To avoid this duplication it is better to modify as_do_pg() to call > something like ssi_install_arg_page() which is install_arg_page() without > force_sig() in error path. > > On Sat, Apr 17, 2010 at 2:36 PM, John Hughes <jo...@ca...> wrote: > >> John Hughes wrote: >> >> John Hughes wrote: >>> >>>> >>>> pud = pud_offset(pgd, apip->api_addr); >>>> >>> It seems than when we get here "pgd_none (pgd)" is true, so maybe we >>> should be doing a pud_alloc instead of just "pud = pud_offset(...)". >>> >>> But it doesn't seem to work, that just makes us hang. >>> >> Because I screwed up. >> >> Yes, we should be doing pud_alloc, not just pud_offset. >> >> This patch makes migration work. >> >> Well, almost. The migrated process seems not to be able to access its >> terminal. >> >> >> >> >> >> ------------------------------------------------------------------------------ >> Download Intel® Parallel Studio Eval >> Try the new software tools for yourself. Speed compiling, find bugs >> proactively, and fine-tune applications for parallel performance. >> See why Intel Parallel Studio got high marks during beta. >> http://p.sf.net/sfu/intel-sw-dev >> _______________________________________________ >> ssic-linux-devel mailing list >> ssi...@li... >> https://lists.sourceforge.net/lists/listinfo/ssic-linux-devel >> >> > |
From: John H. <john@Calva.COM> - 2010-04-18 10:35:10
|
Roger Tsang wrote: > Further it appears as_do_pg() is just a dupe of Linux > install_arg_page(). To avoid this duplication it is better to modify > as_do_pg() to call something like ssi_install_arg_page() which is > install_arg_page() without force_sig() in error path. However install_arg_page disappears in 2.6.23 |
From: John H. <john@Calva.COM> - 2010-04-17 11:13:57
|
John Hughes wrote: > With the current x86_64 kernel [migration] no longer crashes. :-) > Nope, migration using /proc/xxx/goto doesn't crash but migration with sys_migrate crashes. Entering kdb (current=0xffff81001f1d4720, pid 69223) on processor 0 Oops: <NULL> due to oops @ 0xffffffff801794a2 r15 = 0x0000000000000000 r14 = 0xffff81001d0f6128 r13 = 0xffff81001d20e098 r12 = 0xffff81001d0f60c0 rbp = 0xffff81001d842800 rbx = 0x0000000000600000 r11 = 0xffff81001d45c440 r10 = 0xffff81001fb6c440 r9 = 0xffff81001fff5f68 r8 = 0xffff81001fff5f58 rax = 0x0000ff5300000018 rcx = 0x03fffffffffff000 rdx = 0x0000000000600000 rsi = 0x0000805300000018 rdi = 0xffff81001d0f60c0 orig_rax = 0xffffffffffffffff rip = 0xffffffff801794a2 cs = 0x0000000000000010 eflags = 0x0000000000010296 rsp = 0xffff81001f79bc10 ss = 0xffff81001f79a000 ®s = 0xffff81001f79bb78 [0]kdb> bt Stack traceback for pid 69223 0xffff81001f1d4720 69223 2 1 0 R 0xffff81001f1d49e0 *a.out RSP RIP Function (args) 0xffff81001f79bc10 0xffffffff801794a2 pte_alloc_map+0x22 (0x0, 0x0, 0xffff81001d0f6110, 0x0, 0x1) 0xffff81001f79bc58 0xffffffff8026fc89 as_untranscribe+0x5e9 (0x0, 0xffff81001d0f60c0, 0x0, 0xffff81001f9f3a00, 0x4) 0xffff81001f79bd08 0xffffffff8026b917 full_data_unload_msg+0x57 (0xffff810000000001, 0xffffffff803c0e58, 0xffff81001f9a6640, 0x10e64, 0x0) 0xffff81001f79bd38 0xffffffff8026c21d migrate_pproc_unload_msg+0xfd (0x20, 0x1, 0xffff81001df561f0, 0x0, 0x300000000) 0xffff81001f79bd98 0xffffffff8026a1a3 migrate_server+0xf3 (0x73, 0xffff8100019097c0, 0x1f79be88, 0x386, 0xffff81001df561f0) 0xffff81001f79be68 0xffffffff80269163 migrate_server_setup+0x73 0xffff81001f79bf58 0xffffffff80110a38 child_rip+0x8 [0]kdb> We appear to be here: static int as_do_pg(as_pg_info *apip, as_info *asip) { int error = 0; struct mm_struct *mm = current->mm; struct vm_area_struct *vma; pgd_t * pgd; pud_t * pud; pmd_t * pmd; pte_t * pte; down_write(&mm->mmap_sem); if (!(vma = find_vma(mm, apip->api_addr))) { error = -EINVAL; goto out_unlock_sem; } if (unlikely(anon_vma_prepare(vma))) { error = -EAGAIN; goto out_unlock_sem; } flush_dcache_page(apip->api_page); pgd = pgd_offset(mm, apip->api_addr); pud = pud_offset(pgd, apip->api_addr); spin_lock(&mm->page_table_lock); if (!(pmd = pmd_alloc(mm, pud, apip->api_addr))) { error = -EAGAIN; goto out_unlock_spin; } if (!(pte = pte_alloc_map(mm, pmd, apip->api_addr))) { ^^^ BANG! error = -EAGAIN; goto out_unlock_spin; } |
From: John H. <john@Calva.COM> - 2010-04-17 14:11:01
|
John Hughes wrote: > > static int > as_do_pg(as_pg_info *apip, as_info *asip) > { > int error = 0; > struct mm_struct *mm = current->mm; > struct vm_area_struct *vma; > pgd_t * pgd; > pud_t * pud; > pmd_t * pmd; > pte_t * pte; > > down_write(&mm->mmap_sem); > if (!(vma = find_vma(mm, apip->api_addr))) { > error = -EINVAL; > goto out_unlock_sem; > } > if (unlikely(anon_vma_prepare(vma))) { > error = -EAGAIN; > goto out_unlock_sem; > } > flush_dcache_page(apip->api_page); > pgd = pgd_offset(mm, apip->api_addr); > pud = pud_offset(pgd, apip->api_addr); It seems than when we get here "pgd_none (pgd)" is true, so maybe we should be doing a pud_alloc instead of just "pud = pud_offset(...)". But it doesn't seem to work, that just makes us hang. |
From: John H. <john@Calva.COM> - 2010-04-17 18:37:07
Attachments:
as-xscribe-64bit.patch
|
John Hughes wrote: > John Hughes wrote: >> >> pud = pud_offset(pgd, apip->api_addr); > It seems than when we get here "pgd_none (pgd)" is true, so maybe we > should be doing a pud_alloc instead of just "pud = pud_offset(...)". > > But it doesn't seem to work, that just makes us hang. Because I screwed up. Yes, we should be doing pud_alloc, not just pud_offset. This patch makes migration work. Well, almost. The migrated process seems not to be able to access its terminal. |
From: John H. <john@Calva.COM> - 2010-04-18 11:14:16
|
John Hughes wrote: > > This patch makes migration work. > Migration using migrate(2) now works. Migration using /proc/$$/goto seems to be ignored. I wonder why. |
From: Roger T. <rog...@gm...> - 2010-04-18 19:26:31
|
Have you tried tracing the call path? Writing to /proc/$$/goto should traverse.. proc_ssi_write pvpop_procfs_write do_ssi_write setup_execnode_move where TIF_MIGPENDING flag is set. Then do_notify_resume do_signal ssi_quiesce_movement On Sun, Apr 18, 2010 at 7:14 AM, John Hughes <jo...@ca...> wrote: > John Hughes wrote: > > > > This patch makes migration work. > > > Migration using migrate(2) now works. > > Migration using /proc/$$/goto seems to be ignored. > > I wonder why. > > > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > ssic-linux-devel mailing list > ssi...@li... > https://lists.sourceforge.net/lists/listinfo/ssic-linux-devel > |
From: John H. <john@Calva.COM> - 2010-04-19 09:02:43
|
Roger Tsang wrote: > Have you tried tracing the call path? > > Writing to /proc/$$/goto should traverse.. > proc_ssi_write > pvpop_procfs_write > do_ssi_write > setup_execnode_move where TIF_MIGPENDING flag is set. > > Then > do_notify_resume > do_signal > ssi_quiesce_movement Thanks for the tips, I'll try this today. |
From: John H. <john@Calva.COM> - 2010-04-19 11:32:20
|
Looks like a whole bunch of stuff is missing from linux/arch/x86_64/kernel/signal.c |
From: John H. <john@Calva.COM> - 2010-04-20 08:46:16
Attachments:
x86_64.patch
test.c
|
John Hughes wrote: > Looks like a whole bunch of stuff is missing from > linux/arch/x86_64/kernel/signal.c > Quickly hacking in some stuff copied from the i386 version gets me to the point where my test program is segfaulting on the destination node. Needs some more debugging. Maybe I need to merge in Rogers latest changes from CVS. node1$ ./test 2 node2$ test[68412]: segfault at 00002aaaab2226f8 rip 00002aaaaaab8198 rsp 00007fffffa9d2a0 error 4 |
From: John H. <john@Calva.COM> - 2010-04-21 19:40:29
|
On 20/04/10 11:04, John Hughes wrote: > John Hughes wrote: >> Looks like a whole bunch of stuff is missing from >> linux/arch/x86_64/kernel/signal.c > Quickly hacking in some stuff copied from the i386 version gets me to > the point where my test program is segfaulting on the destination node. > > Needs some more debugging. Maybe I need to merge in Rogers latest > changes from CVS. > > node1$ ./test 2 > > node2$ > test[68412]: segfault at 00002aaaab2226f8 rip 00002aaaaaab8198 rsp > 00007fffffa9d2a0 error 4 Still getting this after merging all Rogers changes. Some more debugging to do this weekend... |
From: John H. <john@Calva.COM> - 2010-04-24 14:49:21
|
On 20/04/10 11:04, John Hughes wrote: > Quickly hacking in some stuff copied from the i386 version gets me to > the point where my test program is segfaulting on the destination node. > I cannot understand why migrate(2) works but /proc/xxx/goto doesn't. The process is clearly being migrated to the destination node, but it segfaults (almost?) immediately on arrival. |
From: Roger T. <rog...@gm...> - 2010-04-24 19:27:32
|
On Sat, Apr 24, 2010 at 10:49 AM, John Hughes <jo...@ca...> wrote: > On 20/04/10 11:04, John Hughes wrote: > >> Quickly hacking in some stuff copied from the i386 version gets me to the >> point where my test program is segfaulting on the destination node. >> >> I cannot understand why migrate(2) works but /proc/xxx/goto doesn't. > > The process is clearly being migrated to the destination node, but it > segfaults (almost?) immediately on arrival. > > x86_64 entry.S does FIXUP_TOP_OF_STACK before calling sys_migrate but not in the signal path. This macro mangles rsp to point to the user segments. Maybe this explains why /proc/xxx/goto doesn't work properly. |
From: John H. <john@Calva.COM> - 2010-04-25 15:29:15
|
Well, it looks like some stuff that was in x86_64 port on OpenSSI stable (kernel 2.4) seems to have been forgotten. For example in arch/x86_64/kernel/sys_x86_64.c there was some stuff for MAP_MIGRATE. I'll try and see if some of this should be ported forward. |
From: John H. <john@Calva.COM> - 2010-04-25 16:08:08
|
Here is the list of code that has been possibly incorrectly dropped in the x86_64 port. arch/x86_64/kernel/sys_x86_64.c code in mmap to check the MAP_MIGRATE flag. The base code is rather different so I'm not sure how to deal with this yet. arch/x86_64/lib/csum-wrappers.c csum_partial_copy_from_user - cope with remote user process arch/x86_64/tools/offset.c Definition of thread_rsp0 - used in ret_from_rproc in entry.S Not needed any more, ret_from_rproc has changed. A whole bunch of stuff in arch/x86_64/ia32. Probably only relevant for 32bit libcluster. To be done later. |
From: John H. <john@Calva.COM> - 2010-04-26 18:58:12
|
On 25/04/10 18:07, John Hughes wrote: > Here is the list of code that has been possibly incorrectly dropped in > the x86_64 port. > > arch/x86_64/kernel/sys_x86_64.c > > code in mmap to check the MAP_MIGRATE flag. The base code is > rather different so I'm not sure how to deal with this yet. > So what does this do? Normally mmap and it's subroutines use address 0 to mean "map wherever you want". When we migrate mappings across to a new node if there is a mapping at address 0 we want it to be at the same address on the destination node. So, in mmap we make sure the MAP_MIGRATE flag is off: e.g. in arch/i386/kernel/sys_i386.c: #ifdef CONFIG_SSI flags&= ~MAP_MIGRATE; #endif When moving mappings we put it on in cluster/ssi/vproc/as_xscribe.c, static int as_do_vma(as_vma_info *avip, as_info *asip) ... flags |= MAP_MIGRATE; And when we do the work, for i386 in ./include/linux/mm.h #ifndef HAVE_ARCH_UNMAPPED_AREA unsigned long arch_get_unmapped_area(struct file *filp, unsigned long addr, unsigned long len, unsigned long pgoff, unsigned long flags) { ... #ifdef CONFIG_SSI if (addr || (flags& MAP_MIGRATE)) #else if (addr) #endif { addr = PAGE_ALIGN(addr); vma = find_vma(mm, addr); if (TASK_SIZE - len>= addr&& (!vma || addr + len<= vma->vm_start)) return addr; } Problem for x86_64 is that it has HAVE_ARCH_UNMAPPED_AREA so we need to do some more work. Which turns out to be not so much really: Index: sys_x86_64.c =================================================================== RCS file: /cvsroot/ssic-linux/openssi/kernel/arch/x86_64/kernel/sys_x86_64.c,v retrieving revision 1.1.1.1 retrieving revision 1.3 diff -u -p -r1.1.1.1 -r1.3 --- sys_x86_64.c 26 Apr 2010 18:44:42 -0000 1.1.1.1 +++ sys_x86_64.c 26 Apr 2010 18:56:01 -0000 1.3 @@ -51,6 +51,9 @@ long sys_mmap(unsigned long addr, unsign error = -EBADF; file = NULL; flags&= ~(MAP_EXECUTABLE | MAP_DENYWRITE); +#ifdef CONFIG_SSI + flags&= ~MAP_MIGRATE; +#endif if (!(flags& MAP_ANONYMOUS)) { file = fget(fd); if (!file) @@ -105,7 +108,11 @@ arch_get_unmapped_area(struct file *filp if (len> end) return -ENOMEM; +#ifdef CONFIG_SSI + if (addr || (flags& MAP_MIGRATE)) { +#else if (addr) { +#endif addr = PAGE_ALIGN(addr); vma = find_vma(mm, addr); if (end - len>= addr&& |