oops!
Оказывается на svn://programs/develop/fast_call_test лежит с пустыми циклами (реальные вызовы закомментированы)
сегодня прогнал заново - всё как доктор прописал:
SYSENTER - в среднем 180 тактов на вызов,
SYSCALL ~140 тактов
INT40 около 250.
Новый init.inc (без цикла .noPSE) залил на SVN
Новая модель ядра
-
Евангелие от Иоанна: стих 1[/size]
Code: Select all
; В начале было Слово: B32: mov ax, os_stack ; Selector for os
А что это за изменения в svn.1454? Цикл в init_page_map вообще-то помечает свободные/занятые физические страницы, а статические физические адреса - это всё до sys_pgmap плюс некоторое количество памяти после (причём, как мне показалось, суммарное количество может и перевалить за 4M - почему я и поставил безопасное значение 0x5FFFF80 для TSS в фиксе svn.1310... хотя, может быть, просто показалось).
И насчёт PSE... DosBox с подходящими настройками может загрузить Колибри, но понятия не имеет про большие страницы. Оно, конечно, понятно, что это явно нецелевое использование dosbox (как следует прямо из названия) и т.д. и т.п., но разве несколько строчек, обрабатывающих случай отсутствия PSE, чем-то мешают?
И насчёт PSE... DosBox с подходящими настройками может загрузить Колибри, но понятия не имеет про большие страницы. Оно, конечно, понятно, что это явно нецелевое использование dosbox (как следует прямо из названия) и т.д. и т.п., но разве несколько строчек, обрабатывающих случай отсутствия PSE, чем-то мешают?
Ушёл к умным, знающим и культурным людям.
diamond
Верхняя граница таблицы страниц (адрес "а") сейчас не определена и действительно может (и будет) вываливаться за линию 4Мб.
ИМХО включение неиспользуемого при инициализации диапазона [a, 4M) в список свободных страниц приводит к ненужному кроссмаппингу и разрыву логически цельной системной области. "Почти тривиальное" страничное преобразование адресов при этом не просто ломается выше "а" - его вообще не существует ни для одной 4К-страницы.
Это, конечно, не смертельно. Только зачем усложнять, когда можно упростить?
Насчет PSE: теперь буду знать что хоть где-то она нужна. Верну назад.
Верхняя граница таблицы страниц (адрес "а") сейчас не определена и действительно может (и будет) вываливаться за линию 4Мб.
ИМХО включение неиспользуемого при инициализации диапазона [a, 4M) в список свободных страниц приводит к ненужному кроссмаппингу и разрыву логически цельной системной области. "Почти тривиальное" страничное преобразование адресов при этом не просто ломается выше "а" - его вообще не существует ни для одной 4К-страницы.
Это, конечно, не смертельно. Только зачем усложнять, когда можно упростить?
Насчет PSE: теперь буду знать что хоть где-то она нужна. Верну назад.
Евангелие от Иоанна: стих 1[/size]
Code: Select all
; В начале было Слово:
B32: mov ax, os_stack ; Selector for os
Подниму тему.
Сейчас окно получает сообщения от мыши независимо от того активно, оно или нет. Это приводит к тому, что окна спамятся потоком ненужных событий. Я предлагаю добавить к маске событий один бит, чтобы окно получало события от мыши только в активном состоянии. Это не повлияет на работу уже существующих программ, новые смогут включать фильтрацию мыши.
Сейчас окно получает сообщения от мыши независимо от того активно, оно или нет. Это приводит к тому, что окна спамятся потоком ненужных событий. Я предлагаю добавить к маске событий один бит, чтобы окно получало события от мыши только в активном состоянии. Это не повлияет на работу уже существующих программ, новые смогут включать фильтрацию мыши.
So you mean a new bit wich can be set using function 40, wich the application can use to receive mouse events only when the window is active?Serge wrote:Подниму тему.
Сейчас окно получает сообщения от мыши независимо от того активно, оно или нет. Это приводит к тому, что окна спамятся потоком ненужных событий. Я предлагаю добавить к маске событий один бит, чтобы окно получало события от мыши только в активном состоянии. Это не повлияет на работу уже существующих программ, новые смогут включать фильтрацию мыши.
I like it, go for it.
"Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction." Albert Einstein
За.
Только надо будет потихоньку все старые приложения тоже переделать, чтоб не дергались.
Только надо будет потихоньку все старые приложения тоже переделать, чтоб не дергались.
Не все приложения нужно переделывать - некоторым нужна постоянная обработка событий мыши. В целом идею поддерживаю.
Новая функция 68.26
Предварительное описание.
eax=68
ebx=26
ecx= адрес блока, созданного ф. 68.12
edx= смещение от начала блока
esi = размер освобождаемой области в байтах
Функция выравнивает смещение на начало страницы и округляет размер до величины кратной размеру страницы.
Существующие функции heap_alloc(68.12) heap_free(68.13) heap_realloc(68.20) используют примитивный алгоритм управления виртуальной памятью приложения и не предназначены для активного использования. heap_unmap(68.26) возвращает ядру неиспользуемые страницы памяти, не удаляя блок созданный heap_alloc(). Сами страницы помечаются как зарезервированные и снова выделяются ядром при первом обращении к ним. Таким образом heap_unmap(68.26) позволяет организовать гибкое управление виртуальной памятью средствами приложения.
Возможен другой вариант реализации, когда функция будет освобождать любую страницу в пределах адресного пространства приложения.
Предварительное описание.
eax=68
ebx=26
ecx= адрес блока, созданного ф. 68.12
edx= смещение от начала блока
esi = размер освобождаемой области в байтах
Функция выравнивает смещение на начало страницы и округляет размер до величины кратной размеру страницы.
Существующие функции heap_alloc(68.12) heap_free(68.13) heap_realloc(68.20) используют примитивный алгоритм управления виртуальной памятью приложения и не предназначены для активного использования. heap_unmap(68.26) возвращает ядру неиспользуемые страницы памяти, не удаляя блок созданный heap_alloc(). Сами страницы помечаются как зарезервированные и снова выделяются ядром при первом обращении к ним. Таким образом heap_unmap(68.26) позволяет организовать гибкое управление виртуальной памятью средствами приложения.
Возможен другой вариант реализации, когда функция будет освобождать любую страницу в пределах адресного пространства приложения.
А почему не сохраняется? Это несколько противоречит политике работы с остальными битами.Serge wrote: Значение бита не сохраняется в маске событий, соответственно функция всегда возвращает предыдущее значение маски со сброшенным битом 3.
Насчет 68.26 какая-то нечеткая логика получается. У меня куча вопросов сразу возникла.
1. После повторного обращения нужно снова возвращать через 68.26?
2. Т.е. виртуальная страница примонтирована, а реальная физическая отключена?
3. Какова задержка при таком обращении?
4. Какой типичный пример использования функции?
Mario
Логика уже нарушена, потому что бит 3 соответствует несуществующему событию 4. Изменить значение битов извне невозможно, состояние полностью отслеживается силами приложения. С другой стороны я уже думаю над новой версией. Вместо бита 3 использовать биты 16-17 добавив фильтр по положению курсора за пределами окна.
68.26
1. Да.
2.3 Состояние ничем не отличается от свежесозданного 68.12. Там всё работает точно также. Приложениям в Колибри физическая память всегда выделяется при первом обращении. Точную задержку подсчитать сложно. Это время на поиск страницы в битовой карте и её обнуление. От нескольких тысяч тактов до следующего цикла планировщика если не успели.
4. Собственный менеджер виртуальной памяти если ему требуется работать с большой нагрузкой. Или буфер переменной длины. Например для битмапа. В текущей ситуации браузер или графической редактор с кучей слоёв, масок и историей операций рискуют зависнуть в самый неподходящий момент. 68.26 позволяет возвращать ядру физическую память, которая не нужна в это время и в этом месте. И получать её снова при первой необходимости. Если она ещё осталась у ядра.
Логика уже нарушена, потому что бит 3 соответствует несуществующему событию 4. Изменить значение битов извне невозможно, состояние полностью отслеживается силами приложения. С другой стороны я уже думаю над новой версией. Вместо бита 3 использовать биты 16-17 добавив фильтр по положению курсора за пределами окна.
68.26
1. Да.
2.3 Состояние ничем не отличается от свежесозданного 68.12. Там всё работает точно также. Приложениям в Колибри физическая память всегда выделяется при первом обращении. Точную задержку подсчитать сложно. Это время на поиск страницы в битовой карте и её обнуление. От нескольких тысяч тактов до следующего цикла планировщика если не успели.
4. Собственный менеджер виртуальной памяти если ему требуется работать с большой нагрузкой. Или буфер переменной длины. Например для битмапа. В текущей ситуации браузер или графической редактор с кучей слоёв, масок и историей операций рискуют зависнуть в самый неподходящий момент. 68.26 позволяет возвращать ядру физическую память, которая не нужна в это время и в этом месте. И получать её снова при первой необходимости. Если она ещё осталась у ядра.
Т.е. наличие свободной памяти у ядра негарантированно в любом случае. Как же тогда данные о том сколько памяти приложение занимает? Получается с виду оно занимает одно количество памяти, а на само деле занимает меньше. Что будет, когда приложение "ничтоже сумняшеся" пытается записать в виртуально примонтированную страницу данные и ВНЕЗАПНО свободной памяти нет. Какое событие или исключение происходит и обрабатывается ли такая катастрофа вообще?
Mario
Приложение вылетит со страничной ошибкой.
Приложение вылетит со страничной ошибкой.
Кстати, когда я писал zSea то выяснилось что одному потоку гарантированно выделяется от силы 900 Кб памяти - это можно как то исправить?
Почему 900 ? Сколько попросишь, столько и выделится.
Упс... я неправильно выразился - 900 Мб конечно же, а не 900 Кб.
Там какое то ограничение с кучей было, мне Евгений так по крайней мере так объяснил. У меня была ситуация когда теоретически выделялось более 1 Гб памяти (вследствие неправильного увеличения данных в 8 раз) но все падало. Ты когда плоскую модель внедрял, то писал что 4=2+2 будет распределение памяти. виртуальной по крайней мере. Как выяснилось практически приложению гарантированно можно рассчитывать на 900 Мб.
Там какое то ограничение с кучей было, мне Евгений так по крайней мере так объяснил. У меня была ситуация когда теоретически выделялось более 1 Гб памяти (вследствие неправильного увеличения данных в 8 раз) но все падало. Ты когда плоскую модель внедрял, то писал что 4=2+2 будет распределение памяти. виртуальной по крайней мере. Как выяснилось практически приложению гарантированно можно рассчитывать на 900 Мб.
Who is online
Users browsing this forum: No registered users and 7 guests