 |
|
|
ru.unix- RU.UNIX ---------------------------------------------------------------------- From : Valentin Davydov 2:5020/400 04 Aug 2005 20:33:57 To : Andrew Kant Subject : Re: Уцелеть перед Майкрософт. help. -------------------------------------------------------------------------------- > From: Andrew Kant <Andrew.Kant@p1.f83.n469.z2.fidonet.org> > Date: Tue, 02 Aug 2005 20:22:04 +0400 > > AK>> Есть еще более крайние меры - виртуальные машины. > AK> где они "есть"-то? >Hу уже почти везде - и на интел-платформе, и те-же мэйнфреймы. Правда, >linux/390 я и в глаза не видел, железо для него найти сложно в наших краях :) >Hо то, что linux/390 прекрасно живет под соответствующей VM/ESA - однозначно. >Однако, вариант его использования для замены колокэйшна мне пока видится >слишком гипотетическим. > > AK>> это накладно с точки зрения ресурсов. Hо в каждой vm можно > AK>> разместить клиента с > AK>> любыми самыми извращенными запросами - у каждого своя ОС. > AK> а теперь немножко подумаем - что помешает мне сожрать из своей ОС все > AK> процессорные ресурсы _реальной_ машины? >Подумали, как ты говоришь. Должен мешать планировщик процессов. Дальше уже >зависит от того, на какой ОС реализован сам монитор виртуальных машин. Мне >больше VM Workstation под XP не нужно, но тому, кто нужно, берет нечто более >продвинутое, ну не верю я что там нет _штатных_ средств для того, чтобы >ограничить потребление ресурсов. > > AK> Как только станет понятно, что помешать этому можно только кривыми > AK> и очень кривыми путями, во всяком случае, на архитектурах а-ля > AK> ix86, поймешь о чем я, собственно, говорил. >Это в любой [нормальной] операционке заложено - процесс работает либо до >прерывания (по собственному желанию или хардверное прерывание), либо до конца >кванта времени (что тоже в принципе есть прерывание). А потом операционка либо >ему дает очередной шанс, либо в очередь, а процессор следующему. Естественно, >что если квант это t милисекунд, то больше чем 1000/t жрущих процессор >процессов за секунду ты не обслужишь, но это и понятно - выше головы не >прыгнешь. Либо уменьшай время t, либо увеличивай мощность (и/или) число >процессоров. Что из этого кривое или нереализуемо на интел-архитектуре? Память. Там квант времени порядка долей микросекунды, но зато это время _вся_ система стоит, а не только приложение, вздумавшее обратиться к незакэшированной в процессоре странице. А ещё диски есть, с которыми во многих ОС встречается аналогичная ситуация (только характерное время общего простоя измеряется десятками миллисекунд). Вал. Дав. >Другое дело, что может быть существующие реализации тебя не устраивают? Hо >тогда причем здесь архитектура? > >Good bye! > Andrew --- ifmail v.2.15dev5.3 * Origin: St. Petersburg State University (2:5020/400) Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
Архивное /ru.unix/441741ab8091.html, оценка из 5, голосов 10
|
|
|