Date: Thu, 29 May 2008 10:53:35 -0700 From: Julian Elischer <julian@elischer.org> To: Marko Zec <zec@icir.org>, Marko Zec <zec@FreeBSD.org>, Robert Watson <rwatson@freebsd.org>, Brooks Davis <brooks@freebsd.org>, freebsd-virtualization@freebsd.org, David O'Brien <obrien@freebsd.org> Subject: vimage steps forward. Message-ID: <483EED9F.6030309@elischer.org>
next in thread | raw e-mail | index | archive | help
I hope to spend a couple of days looking at breaking up the current
patch...
## part 1: all the macros.. the macros will be defined in CURRENT
FILES I think rather than adding new files.
POSSIBLY NOT FOR ALL THE MODULES DONE IN THE CURRENT PATCH.
use MD5 to confirm that there are no editing errors.
## part 2: add the structures and initialisers.
By this time a document should be available describing how to
virtualise modules. Marko, if you can write a few pages on this,
send it to me and I'll add to it and clean it a bit and send it to
you.. I'll then send it back to you.. we can iterate, and I
would suggest that we make it generally available somewhere so
that others can comment and add as they learn.
## part 3:redefine the macros to be able to switch to using the
structures or not.
do some performance tests with
a) global variables
b) structified variables
I and ALC expect that we may need to 'tune' teh structures to
ensure that heavily used items that are accessed by different CPUS
are not in the same cache lines.. i.e. either separated by rarely
used items or by padding and that items used together are clustered.
This may take some time to test but we can probably get a lot of
parallelism by getting many people to do the tests as it will
be relatively easy to do.
## part 4: remove the non-structured versions of the globals and
adjust the macros so that "non" vimage versions use static copies of
the structures.
## part 5: add framework for vimage creation etc.
test
## part 6: start adding more modules, one at a time.
comments:
The structures should be changed from the current form to have a
header in them that is always the same.. As per the discussions
that header should contain a version number and a reference counter,
(and possibly a magic number).
By defining this header somewhere we can add debug assist stuff to it
as needed..
possibly it should also contain some methods and the name of the
module (for example)..
i.e. a method pointer to a function that can tell if the module is in
use.. possibly combinign this structure with other per-module
structures could be considered.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?483EED9F.6030309>