Re: copy on write memory

[Peri Hankey <mpah@thegreen.co.uk>]

I tried applying  it in a spirit of pure optimism (naivety). You never know.

To return for one moment to the thing I was chasing. Let's assume that 
in its standard configuration the Linux (or indeed some other kernel) 
makes a very good job of sharing memory across processes by means of the 
copy-on-write fork semantics and by exploiting the overall view that it 
has of how pages/blocks are read from the filesystem and modified by 
processes. Let's hope that it (or they) get even better. We would like 
separate xenU domains to benefit from the excellence that exists and the 
improvements that may be.

My idea is to use a memory-privileged xenU domain as a page-table 
manager for a group of client domains. It would have to know about the 
memory/page/block usage of every process in each of its clients as if 
they were all running within it. But it would never operate as the 
actual kernel for any of these processes. For those purposes each 
process would operate under the supervision of a memory-client domain 
that has its own kernel address space.

I haven't at present got the intimate knowledge of memory management 
traffic between xen, xen0 and xenU domains that I would need to see 
whether or not this idea has any legs. But I am very interested to know 
what anyone thinks. No doubt the best answer is to go and study the code.

Anyway, thanks for your help, and for your quick repsonse. Much quicker 
than mine.

Regards
Peri

urmk@reason.marist.edu wrote:

>>It's true, you did mention it before, but I was looking for something 
>>else at the time. What I have in mind doesn't require so much 
>>configuration. On the other hand it doesn't exist, and this does.
>>    
>>
>
>Ah.  I couldn't remember if I'd sent it or not (or if I'd even tried to send
>it from an address that was on the list, a few go to the same mailbox at 
>the moment)
>
>  
>
>>But the patch is against quite an old source, and it doesn't compile 
>>straight out of the box. Do you know if there are updated patches 
>>against 2.6.9?
>>    
>>
>
>I can check.
>
>  
>
>>I get this error (which I haven't yet examined in detail):
>>
>> CC [M]  fs/xip2fs/file.o
>>fs/xip2fs/file.c: In function `xip2_do_file_read':
>>fs/xip2fs/file.c:69: error: structure has no member named `buf'
>>fs/xip2fs/file.c: In function `__xip2_file_aio_read':
>>fs/xip2fs/file.c:119: error: structure has no member named `buf'
>>fs/xip2fs/file.c: In function `xip2_file_sendfile':
>>fs/xip2fs/file.c:302: error: structure has no member named `buf'
>>
>>This was against xen-2.0.1 as of today 18 Nov 2004
>>    
>>
>
>I highly doubt that it will be directly applicable to xen - the entire backend
>mechanism is linked into the z/VM shared memory system between guests.  I was
>more pointing it out as a probable jumping off point (most of the work is done,
>it just needs to use the xen memory sharing instead) and as a workable
>concept for a less-cpu-intensive copy-on-write mechanism.
>
>I'll take a look for a newer patch and see if I can scrape up some time to
>apply the backend to xen, but I don't know when I'll get a chance -- don't let
>me hold anyone else up who was considering working on it.
>
>-m
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: InterSystems CACHE
>FREE OODBMS DOWNLOAD - A multidimensional database that combines
>robust object and relational technologies, making it a perfect match
>for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8
>_______________________________________________
>Xen-devel mailing list
>Xen-devel@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/xen-devel
>
>
>  
>


-------------------------------------------------------
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8