It seems to me that Xen is full of stuff that aren''t beneficial for everybody, this includes NUMA, ACM and other stuff that certain companies try to introduce... In a better world, the Xen binary would have been more sleek and fast, and those extra features should be loaded via stating a Module boot line in Grub. This way, testing would be easy and it''s more elegant than using a compilation flag. Are there any thoughts to make Xen more modular in this manner? It can be a real improvement for all of us freelancers that experiment with this hot subject :) Your thoughts? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 15/1/07 17:30, "David Pilger" <pilger.david@gmail.com> wrote:> It seems to me that Xen is full of stuff that aren''t beneficial for > everybody, this includes NUMA, ACM and other stuff that certain > companies try to introduce... In a better world, the Xen binary would > have been more sleek and fast, and those extra features should be > loaded via stating a Module boot line in Grub. This way, testing would > be easy and it''s more elegant than using a compilation flag. > > Are there any thoughts to make Xen more modular in this manner? > It can be a real improvement for all of us freelancers that experiment > with this hot subject :)I personally don''t think this is worthwhile, at least right now. The Xen image is about 1MB in memory (including text, data and bss) which is very little even for portable devices these days. If someone is dead set on investigating this then I would also say that it''s rather nice having all of the Xen features in a single binary. One option might be to place some features into their own sections and free those at boot time if it turns out a feature is not required for this particular system or boot configuration. This could be applied for example to Intel- and AMD-specific code. The cost of having a monolithic Xen image rather than specifically chosen modules is inconsequential (again, even worst case of an embedded application consider size of modern flash devices). -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 1/15/07, Keir Fraser <keir@xensource.com> wrote:> I personally don''t think this is worthwhile, at least right now. The Xen > image is about 1MB in memory (including text, data and bss) which is very > little even for portable devices these days.Hi Keir, I look at it from the perspective of extending instead of embeding... This way, Xen will be easily ported to any environment, it will be much more easier to program extensions, etc... _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Makes a lot of sense IMHO. It would also provide for better opportunity in extending Xen - some of the features can really "get in your way" when you''re trying to add new features. This, for features you don''t really need (did someone say NUMA?). Suppose I would be able to easily take out redundant stuff (without having to go into the code and comment out a zillion lines of code), I would be able to more easily develop initial implementations of new features. Later, I would put everything back in and make sure it all works together. But that''s the final stage of such a project, shouldn''t be mandatory at the pilot stages... My 2c Ilan Horn Chief Software Architect, Neocleus Inc. -----Original Message----- From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of David Pilger Sent: Monday, January 15, 2007 7:30 PM To: xen-devel@lists.xensource.com Subject: [Xen-devel] Modular Xen It seems to me that Xen is full of stuff that aren''t beneficial for everybody, this includes NUMA, ACM and other stuff that certain companies try to introduce... In a better world, the Xen binary would have been more sleek and fast, and those extra features should be loaded via stating a Module boot line in Grub. This way, testing would be easy and it''s more elegant than using a compilation flag. Are there any thoughts to make Xen more modular in this manner? It can be a real improvement for all of us freelancers that experiment with this hot subject :) Your thoughts? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> Hi Keir, I look at it from the perspective of extending instead of > embeding... This way, Xen will be easily ported to any environment, it will > be much more easier to program extensions, etc...Is this really the case, though? Assuming we''re not talking about dynamically loadable modules here, there would seem to be a fairly limited gain in ease of extension: Xen compiles *very* quickly already, sufficiently so that it''s not particularly significant compared to the time taken to reboot your machine to test your changes. I wouldn''t expect the ability to recompile a module separately to make much difference to this... There are circumstances where it might be nice to load *something* into Xen at boot time though... I think the ACM / sHype work supports (or at least, supported at some stage) loading policy data as a multiboot module. Cheers, Mark -- Dave: Just a question. What use is a unicyle with no seat? And no pedals! Mark: To answer a question with a question: What use is a skateboard? Dave: Skateboards have wheels. Mark: My wheel has a wheel! _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> -----Original Message----- > From: xen-devel-bounces@lists.xensource.com > [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of > Mark Williamson > Sent: Tuesday, January 16, 2007 6:56 PM > To: xen-devel@lists.xensource.com > Cc: Keir Fraser; David Pilger > Subject: Re: [Xen-devel] Modular Xen > > > Hi Keir, I look at it from the perspective of extending instead of > > embeding... This way, Xen will be easily ported to any > environment, it > > will be much more easier to program extensions, etc... > > Is this really the case, though? > > Assuming we''re not talking about dynamically loadable modules > here, there would seem to be a fairly limited gain in ease of > extension: Xen compiles > *very* quickly already, sufficiently so that it''s not > particularly significant compared to the time taken to reboot > your machine to test your changes. > > I wouldn''t expect the ability to recompile a module > separately to make much difference to this... >I don''t think that compilation is the main issue discussed. Porting is a good example where loadables modules are useful... assuming that not all platforms support all of Xen features. Keeping track of what happen in this list for a while and I can definitely say that there is a "feature contention" around :) A modular approach can be a great improvement IMHO. -- Guy.> There are circumstances where it might be nice to load > *something* into Xen at boot time though... I think the ACM > / sHype work supports (or at least, supported at some stage) > loading policy data as a multiboot module. > > Cheers, > Mark > > -- > Dave: Just a question. What use is a unicyle with no seat? > And no pedals! > Mark: To answer a question with a question: What use is a skateboard? > Dave: Skateboards have wheels. > Mark: My wheel has a wheel! > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>Mark Williamson wrote: > > > There are circumstances where it might be nice to load *something* > into Xen at boot time though... I think the ACM / sHype work supports>(or at least, supported at some stage) loading policy data as a multiboot> module. > > Cheers, > MarkIndeed, ACM/sHype supports dynamic loading of security policies at boot time. The policy can be provided as a multiboot module. We are planning to go one step further and add a legacy (non-security) mode to the ACM. Then, an ACM-enabled Xen kernel will offer users the option to switch security on and off at boot time without recompilation. Thanks Reiner _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Mon, 2007-01-15 at 19:30 +0200, David Pilger wrote:> It seems to me that Xen is full of stuff that aren''t beneficial for > everybody, this includes NUMA, ACM and other stuff that certain > companies try to introduce...can anyone explain to me what the current numa-bashing is all about? i''m running a lot of my stuff on 4-way opteron servers, these system are far from uncommon these days and certainly beyond a mere ''introduction attempt''. are there any numbers regarding the code size/performance penalty on systems limited to a single memory node? i''d really be interested. regards, daniel -- Daniel Stodden LRR - Lehrstuhl für Rechnertechnik und Rechnerorganisation Institut für Informatik der TU München D-85748 Garching http://www.lrr.in.tum.de/~stodden mailto:stodden@cs.tum.edu PGP Fingerprint: F5A4 1575 4C56 E26A 0B33 3D80 457E 82AE B0D8 735B _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
As can be seen in some of my rants, I am also in some love/hate relationship with Xen. I agree about general doubts on the maturity and robustness of Xen, the openness of it''s development model and lacking communication/documentaion. (Still waiting to hear why there''s no NEWS file for user visible changes in new versions, as most high quality Open Source projects are expected to have, and actually have - there might be some reluctance to tell me that XenEnterprise licenses sell too bad if using the GPL stuff is too easy - just a thought :) ) But I don''t understand this one: On 1/15/07, David Pilger <pilger.david@gmail.com> wrote:> On 1/15/07, Keir Fraser <keir@xensource.com> wrote: > > I personally don''t think this is worthwhile, at least right now. The Xen > > image is about 1MB in memory (including text, data and bss) which is very > > little even for portable devices these days. > > Hi Keir, I look at it from the perspective of extending instead of embeding...In what do you want to embed Xen in? In an embedded system?> This way, Xen will be easily ported to any environment,What do you mean? other architectures, like ARM and MIPS or something? A PPC port is on it''s way. The Xen core is not so big as you suggest, I am no low-level programmer to be able to judge but at least in compile time, the Linux kernel takes most of the time when building Xen. And the ACM /sHype stuff you talk about _is_ in fact optional and not built by default. (I agree with doubts of it''s usefullness in the current state and without further explanation of a usage scenario, see my post about this)>it will be > much more easier to program extensions, etc...Look at the Xen python apis and programs and start programming extensions. If you mean not the tools, but the Xen core, what type of extensions do you mean? There seems to be a flexible architecture, for example to implement different CPU schedulers. What exactly are you missing? If you want a small and sleek virtualization api to port on whatever other architecture, you might want to look at kvm and lhype/ll. But for hardware virtualization - how many platforms apart from AMD SVM, Intel VT/x and IBM Power support this? So, there''s nothing to port them to, I guess. Kvm is part of mainstream linux and will even get PV sometime soon. With a GRML live cd, you can apt-get install kvm, load the module, and start a windows in about 5 minutes. In case you tried both - remember how long ot took you to get your first Xen VM? That''s astonishing for such a new technology! If you are for simplicity and something very small, that might be of interest. That doesn''t mean Xen hasn''t interesting and good upsides compared to kvm. I am, as said in another thread, also sceptical about some of Xen''s features, and some important things might be missing ( I heard no transaction management for migration exists?!) But that''s what wishlist bugs in the BTS are for... not random, un-detailed rants about being "not modular enough". My opinion on this opinion :) Henning _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel