Re: Would SSI clustering extensions be of interest to kernelcommunity?

[Constantine Gavrilov <constg@qlusters.com>]

Alan Cox wrote:

>Ar Llu, 2006-10-16 am 14:49 +0200, ysgrifennodd Constantine Gavrilov:
>  
>
>>2) Are kernel maintainers interested in clustering extensions to Linux 
>>kernel? Do they see any value in them? (Our code does not require kernel 
>>changes, but we are willing to submit it for inclusion if there is 
>>interest.)
>>    
>>
>
>If they are doing SSI well and do not need core kernel changes then yes
>they sound very interesting to me. Historically the big concern has
>always been that things like this muck up the kernel core which affects
>the other 99.99999% of users who don't want SSI clustering.
>
>Alan
>
>
>  
>

SSI intrudes kernel in two places: a) IO system calls, b ) page fault  
code for shared memory pages.

a) IO system calls are "packed" and forwarded to the "home" node, where 
original syscall code is executed.
b) A hook is inserted into page fault code that brings shared memory 
pages from other nodes when necessary.

Apart from these two hooks, SSI code is a "standalone" kernel API add-on 
("add", not "change").

Currently, we can do both "intrusions" from the kernel module. I assume 
that if we submit code, you will require a kernel patch that explicitly 
calls our hooks.

Also, continuous SSI in-kernel support may require SSI changes in the 
following cases: a) new fields in task struct that reflect process state 
(may affect task migration), b) changes in the page fault mechanism (may 
effect SSI shared memory code that brings and invalidates pages), c) 
addition of new system calls (may require implementation of  SSI 
suspport for them).

-- 
----------------------------------------
Constantine Gavrilov
Kernel Developer
Qlusters Software Ltd
1 Azrieli Center, Tel-Aviv
Phone: +972-3-6081977
Fax:   +972-3-6081841
----------------------------------------