Re: [PATCH 1/10] Cr4 is valid on some 486s

[Zachary Amsden]

Arjan van de Ven wrote:

> On Tue, 2005-11-15 at 08:04 -0800, Zachary Amsden wrote:
>  
>
> > Gerd Knorr wrote:
> >
> >    
> >
> > > > Yep, extending alternatives is probably better than duplicating the 
> > > > code.  Maybe having some alternative_smp() macro which places both 
> > > > code versions into the .altinstr_replacement table?  If that sounds 
> > > > ok I'll try to come up with a experimental patch.
> > > >        
> > > i.e. something like this (as basic idea, patch is far away from doing 
> > > anything useful ...)?
> > >      
> > You still need to preserve the originals so that you can patch in both 
> > directions.  
> >    
>
> why do you insist on both directions? That still sounds like real
> overkill to me.
>  

It's not overkill in the virtualization context, and there are 
(struggling, but infinite possibilities) opportunities for native here 
as well.  Run-time SMP->UP->SMP can benefit hotplug (albeit slightly).  
But once you have a basic, generic mechanism for run-time code 
modularization, there is very little cost to adding other features.  
Run-time PAE / non-PAE conversion is far more radical, but not outside 
the realm of possibility - and useful (in both directions) for memory 
hotplug.  Run-time CPU vendor migration is possible, if you, say hotplug 
an AMD chip into a previously Intel socket.

Sure, most of this is science fiction.  But the possibilities are great 
- it's another tool you can use towards modularizing functionality - 
specifically, scattered functionality like CPU instructions, spinlocks, 
and MMU operations that really do deserve to be inlined, and really can 
benefit from taking advantage of faster hardware instruction sequences.  
That the tool already exists in a limited form means that with natural 
extensions, it could easily be refined to allow bi-directional or 
multidirectional run-time choices.

Basically, it removes a lot of the barriers that force configuration 
time choices on the running kernel, and you can start to look at even 
deeply entrenched parts of the kernel as modular.

Zach
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/