Messages in this thread | | | From | Peter Swain <> | Subject | Re: dynamically changing available memory | Date | Sun, 17 May 1998 17:52:52 +1000 (EST) |
| |
> > David Ford wrote: > > it would please me to no end to be able to pull out a failing/failed > > memory module and replace it and the kernel continue on it's merry little > > way. > sure and the simm-dimmdaemon with the knowledge of yer chipset, > will tell ye which rammodule of Bank(0..x) to replace, > 'cause of sig11 and similar HW/Mem_Errors. > > Har, har
well, one day, yes... it doesn't take much, really
as a solution to the how-can-i-use-discontiguous-memory thread, too, one day we should have in-memory images implicitly resident on the 'swapfile' /dev/mem (with a swap_priority of 0, as distinct from the current -1, -2, ...) then we could implement the above proposal with swapoff-like semantics, removing an address range.
what happens to the procs/kernel_structures/etc living there? same as what happens when a swap-space develops errors! if you'rre paranoid enuff, you use mem as a RAID device. not easy, to implement, but that's the generalisation you base it on.
but the easy part which comes with this generalisation is that one can *add* memory --- the gap-at-16Mb and mem-bigger-than-64Mb problems go away when you can just boot a vanilla kernel using at most 15Mb, and then do a "swapon -priority=0 -lo=15Mb -hi=192Mb /dev/mem" from the usual /etc/rc*.
anything with swap-prio >= 0 is real mem!
i can imagine handling that scarce resource of L2 cache as prio==1 and L1 cache as prio==2, and the goodness() function deriving its current-proc-is-favoured policy from posession of a prio==3 resource representing running-on-this-processor. the using-fpu property is similar.
play with it. i suspect linus et al already have this in mind, that's what the -ve swap priorities immediately suggested to me....
Peter Swain ^..^ +61 2 9698 2322 (office) swine@softway.com.au (00) +61 419 431 088 (mobile) Evolutionary software, revolutionary results +61 2 9519 0171 (home)
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |