OSDev http://osdev.su/ |
|
обработка прерываний http://osdev.su/viewtopic.php?f=6&t=586 |
Страница 3 из 4 |
Автор: | Yoda [ 19 июн 2012, 13:19 ] |
Заголовок сообщения: | Re: обработка прерываний |
pavia писал(а): Цитата: Два одновременно запущенных обработчика могут разрушить свои данные. Эти пусть рушат свои данные, главное что-бы ядро жило. А оно систему починет, поднимет.Вот это на мой взгляд серьёзный архитектурный просчёт. Такой подход, вместо создания системы, в которой нет места ошибкам, приводит к созданию системы с постоянными разборками "кто виноват". |
Автор: | pavia [ 19 июн 2012, 13:47 ] |
Заголовок сообщения: | Re: обработка прерываний |
Цитата: Вот это на мой взгляд серьёзный архитектурный просчёт. Такой подход, вместо создания системы, в которой нет места ошибкам, приводит к созданию системы с постоянными разборками "кто виноват". Я это продумывал. Мне и самому ненравится. НО в данном случае защитой было пожертованно в угоду прозводительности. А вся защита ложится на плечи разработчика. Запуск приложений будет разрешён только прошедших проверку и тестирование на соотвестие выполнния стандартов. И там будут зашиты тесты на корректную работу при паролельном исполнении. Корректная работа в паролельном режиме это забота разработчика ПО, а не ОС. хотя некоторые защитные механизмы есть и они скорее всего бдут внедрены. Кто-виноват будет видно легко. Этис собственно система и будет заниматся и вести логи. ПС. Под микроядром я понимаю изолированные процессы. А не процессы в разном адрестном пространстве. Что не обще принято. |
Автор: | Yoda [ 19 июн 2012, 14:02 ] |
Заголовок сообщения: | Re: обработка прерываний |
pavia писал(а): Запуск приложений будет разрешён только прошедших проверку и тестирование на соотвестие выполнния стандартов. Эххх, сними розовые очки. Даже в гигантских корпорациях работают самые обычные люди, которые тоже склонны допускать ошибки. Майкрософтовские драйверы для различного железа ИЗОБИЛУЮТ ошибками. Часто даже сам производитель чипсета не может написать корректный драйвер и (о, Боже!) игнорирует сообщения о найденных ошибках! Я уж не говорю про тысячи более мелких компаний. Многие из них даже не знают о стресс-тестировании драйверов, предусмотренных майкрософтом. pavia писал(а): ПС. Под микроядром я понимаю изолированные процессы. А не процессы в разном адрестном пространстве. Что не обще принято. Не улавливаю разницы. Как изолировать процесс, не изолируя адресные пространства? |
Автор: | SII [ 19 июн 2012, 14:38 ] |
Заголовок сообщения: | Re: обработка прерываний |
Yoda писал(а): Да, сейчас понятия часто путаются. Я подразумеваю следующую классификанию... Спасибо за пояснения. По этой классификации моя система -- гибридная (драйверы могут быть как в составе ядра, так и в виде задач пользовательского режима). А вот микроядро в моём понимании -- то, что здесь названо наноядром. (Собственно, изначально это и подразумевалось под микро-, но дальше, как обычно, пошла "инфляция" понятий). |
Автор: | pavia [ 19 июн 2012, 15:25 ] |
Заголовок сообщения: | Re: обработка прерываний |
Цитата: Не улавливаю разницы. Как изолировать процесс, не изолируя адресные пространства? это моё НОУ-ХАУ. Задачи находятся в одном процессе(имеют одно общее адрестное пространство), но изолируются странцами. Запрещена запись и выполнеие кода. Запись и выполнение кода разрешены только в своей задаче. При переходе от задачи к задачи одни страницы маскируются другие размаскируются. Передача данных эллементарна, так как страницы открыты на чтение. Переход и передача параметров осуществляется через ядро. |
Автор: | Yoda [ 19 июн 2012, 15:33 ] |
Заголовок сообщения: | Re: обработка прерываний |
Что значит "изолируются страницами"? Я так понимаю, это делается перегрузкой содержимого регистра CR3? Если так, то это никакое не ноу-хау, а обычное разделение адресных пространств. То, что ты называешь страницами, открытыми на чтение, традиционно называется Shared memory (разделяемая память). |
Автор: | pavia [ 19 июн 2012, 15:38 ] |
Заголовок сообщения: | Re: обработка прерываний |
Цитата: То, что ты называешь страницами, открытыми на чтение, традиционно называется Shared memory (разделяемая память). У меня вся память Shared memory.CR3 не трогается изменяются только биты отдельных страниц(таблицы страницы). |
Автор: | SII [ 19 июн 2012, 15:40 ] |
Заголовок сообщения: | Re: обработка прерываний |
Скорость переключения классная будет |
Автор: | Yoda [ 19 июн 2012, 17:24 ] |
Заголовок сообщения: | Re: обработка прерываний |
Хммм. В плане скорости... скорость действительно может быть немного больше, если обработчики часто переключаются в рамках общего пространства друг на друга. Однако, в реальности, как я понимаю, переключение на обработчик происходит с какой-то задачи (возникло ведь прерывание). В данном случае перезагрузка CR3 обязательно произойдёт. То есть, скорость может совсем не возрасти. С другой стороны, для всех страниц с перегруженными атрибутами необходимо вызвать инструкцию invlpg, чтобы сбросить скешированные элементы TLB. Таким образом, для этих страниц элементы TLB всё равно будут подгружены заново, а с другой стороны, возрастут накладные расходы на алгоритм сброса кэшированных элементов. Также есть основания полагать, что перезагрузка CR3 на самом деле не сильно бьёт по производительности. Так, на доступ к каждым 4к памяти добавляется только 1 (а на каждые 4М памяти 2) чтение 4 байт из таблиц. В абсолютном исчислении это получится около 0.1% производительности. В плане надёжности... для работы с таким пространством требуется поддержание разделения доступа к страницам, что может внести свои ошибки. Кроме того, тот факт, что вся память по определению разделяемая, добавляет требование к тщательной проверке блокировок доступа. Таким образом, есть основания полагать, что надёжность в такой схеме страдает. Резюме. Моё сугубо личное мнение: такая схема не даст выигрыша в производительности, а скорей всего даже немного проиграет, а также пострадает надёжность. |
Автор: | SII [ 19 июн 2012, 17:29 ] |
Заголовок сообщения: | Re: обработка прерываний |
Так я в плане скорости иронически говорил. Ведь при каждом переключении придётся пробегаться по таблицам переадресации (а они могут быть очень большими), а затем ещё инвалидацию TLB делать (иначе изменения в таблицах не вступят в силу). В результате при каждом переключении будут сыпаться и кэши (из-за чтения-записи большого объёма данных), и TLB. |
Страница 3 из 4 | Часовой пояс: UTC + 3 часа |
Powered by phpBB® Forum Software © phpBB Group http://www.phpbb.com/ |