Messages in this thread | | | Date | Tue, 28 Mar 2000 07:43:19 -0600 (CST) | From | Jesse Pollard <> | Subject | Re: Endless overcommit memory thread. |
| |
With a little word wrap readability edits...
grendel@vip.net.pl (Grendel) > ** On Mar 27, Linda Walsh scribbled: >> Grendel wrote: >>> The clearance levels can be equivalent to the process privilege levels - >>> in respect to memory usage - so that the processes of the most privileged >>> users can be ruled out of the 'kill on OOM' pool - simply marked "non >>> killable". >> --- >> Problem comes when you have two sensitivity labels that are not >> able to be hierarchically compared. They may be at equal sensitivity >> levels but may be in disparate categories that have no ordering -- like >> say, you have the "Harvard University" category and the "Yale University" >> category that have no intrinsic comparable value (other than of the >> attendees or proponents of such :-)). They both have the same sensitivity >> level (say "Faculty" vs. say "Undergrad"). But kernel can't determine a >> hierarchy for the categories.
> Yup, that's definitely a problem. And one that probably requires human > intervention, or a temporary and arbitrary shuffling of priorities within > the same group when the system detects such situation. Somebody earlier > mentioned that in such situation IRIX goes to a deadlock - is it a sensible > behavior?
The deadlock mentioned is usually cleared by memory scheduling activity among batch/interactive jobs. I have seen it under UNICOS, but I don't know if it is available under IRIX.
>>> In a word the processes are guaranteed not to be killed in such situation. >>> If the compartmented mode is to be completely secure, the machine should >>> use separate _hardware_ for every clearance level, or guaranteed >>> separation of VMs, am I correct? >> --- >> Separate hardware may be the ideal. It might be that researchers >> at Harvard and Yale might both wish to have a 256P machine, but the >> reality is that both schools might not be able to afford such a machine >> and but might be able to 'copurchase' such a machine but still want secure >> separation for their research. Covert channels as referred to by Alan C. >> and Jesse P. may have acceptably low bit rates (say <10 bits/second) if what >> they are working on are Gigabit datasets. Obviously, we'd like to know >> what covert channels are possible and what the maximum bit rate of each >> is, so Harvard and Yale can decide if those are acceptable. Their >> requirements might be different than say if Caltech U. and Stanford U. were >> to share a machine.
> Now that I think about it, the compartmented mode on our average PC is quite > improbable :)), but with a cluster of PCs it can be quite possible to do and > very flexible. But what if the Linux kernel supported full virtualization of > all of its sharable resources? That is, it would create full VMs with > virtual network cards, CPUs, pure virtual memory, block devices?
If it is valid in a cluster it must also be valid in the node that controls the cluster. On each node in the cluster it must be valid, although only 3 levels might be active at one time:
SYSHIGH and SYSLOW are always present - the user level might be different at different times, but a node could be dedicated to that level, and most likely that user for the duration of the job. This would lead to more efficent execution on a per-node basis.
The control node must support all levels: I assume that this is also the one to do the accounting, job start, load balancing...).
I would like to have a trusted system so that I can communicate with other systems at a trusted level. I'm not holding my breath yet:)
I think the "full VMs with virtual network cards, CPUs, pure virtual memory, block devices" is overkill. A full MLS kernel includes IPSec for network security, and uses the ESP (extented security packet) information to carry the security labels.
>>> Combining the clearance levels, appropriate capabilities (as you >>> proposed before) and memory access priorities could guarantee that >>> mr. President won't run out of memory :) >> --- >> Ok, zap forward to future. US and Euro countries decide to band >> together to buy a 256GP machine -- to predict the weather, among other >> things. >> Now we have incomparable entities (unless you want to start a squabble). >> Mr. Pres is at the same priority level as other country leaders, but is >> 'incomparable' to them. We can't prioritize memory within that group. If
> Not automatically, no.
Why not? Most systems give interactive jobs a higher scheduling priority than batch jobs, why shouldn't memory scheduling be done too. This is what usually breaks memory deadlocks anyway.
>> there ia memory shortage, Mr. Prez can lobby congress and the other Euro >> nations for more memory on the 256Giga-processor machine. But he won't >> be running along and have his vi session killed out from under him (though >> the concept is a bit amusing...:-)).
> Heh :)))), yeah - that's a bit of a comedy :)). But, what if the Mr. Prez's > process isn't killed but simply put on hold and Mr. Prez sees a nice cute > box popping up on his screen saying "We're sorry - a temporary shortage of > memory caused your process to stop. Please wait patiently." The process is > put on the wait queue until the memory becomes available. To prevent > starvation, the system should be preemptive, of course. The processes in > separate priority groups would be serviced in parallel mode until memory > comes short, then the higher priorities win of course. The processes in the > same priority group would have to be serialized for the access to memory if > the need arises. How about that scenario? No killing, some patience > sometimes :))
Entirely acceptable by me. ------------------------------------------------------------------------- Jesse I Pollard, II Email: pollard@navo.hpc.mil
Any opinions expressed are solely my own.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |