Board.KolibriOS.org

Официальный форум KolibriOS
Текущее время: Чт ноя 15, 2018 11:52 am

Часовой пояс: UTC+03:00




Начать новую тему  Ответить на тему  [ 145 сообщений ]  На страницу Пред. 16 7 8 9 10 След.
Автор Сообщение
 Заголовок сообщения: Re: Fast System Call
СообщениеДобавлено: Чт июл 29, 2010 7:08 pm 
Не в сети
Kernel Developer
Аватара пользователя

Зарегистрирован: Пт авг 14, 2009 1:46 am
Сообщения: 1292
имхо, в заточенных под AMD системах имеет смысл вызывать стандартные сисфункции через int40,

а специализированный сервис и расширенный ioctl драйверов (который на пнях всё равно не пойдет) - через SYSCALL/SYSRET;

с передачей параметров в пользовательском стеке (или в регистрах,- кроме ECX).

На Sempron-140 вызов функции-пустышки через SYSCALL занимает 94 такта (в 2.4 раза быстрее, чем через int40):


Вложения:
SYSCALL.jpg
SYSCALL.jpg [ 38.1 КБ | 5425 просмотров ]

_________________
Узкий специалист подобен флюсу: полнота его - односторонняя.
Козьма Прутков
Вернуться к началу
 Заголовок сообщения: Re: Fast System Call
СообщениеДобавлено: Пт июл 30, 2010 1:07 pm 
Не в сети
Kernel Developer
Аватара пользователя

Зарегистрирован: Пт авг 14, 2009 1:46 am
Сообщения: 1292
Кстати,

Serge, Ghost,

А обязательно ли при вызове сисфункции переключаться в стек нулевого уровня, да еще и с выцарапыванием параметра из третьего кольца:
Код:
;(взято из core/syscall.inc)
syscall_entry:
  ;     cli                 syscall clear IF
        xchg    esp, [ss:tss._esp0]
        push    ecx
        lea     ecx, [esp+4]
        xchg    ecx, [ss:tss._esp0]
        sti
        push    ecx
        mov     ecx, [ecx]
        ;------------------
        pushad
        cld

        movzx   eax, al
        call    dword [servetable2 + eax * 4]

        popad
        ;------------------
        mov     ecx, [ss:esp+4]
        pop     esp
        sysret
Браво, такие выверты даже в Колибри - редкость!
Только зачем?
Переключения задачи ведь все равно не происходит, а возврат в ring3 воможен только через sysret.
Так может, лучше юзерским стеком воспользоваться: быстро, просто, и методически-корректно?

_________________
Узкий специалист подобен флюсу: полнота его - односторонняя.
Козьма Прутков


Вернуться к началу
 Заголовок сообщения: Re: Fast System Call
СообщениеДобавлено: Сб июл 31, 2010 8:52 am 
Не в сети
Kernel Developer

Зарегистрирован: Ср мар 08, 2006 6:25 pm
Сообщения: 3952
art_zh
Выносим ядро ?
Код:
xor esp, esp
sysenetr


Вернуться к началу
 Заголовок сообщения: Re: Fast System Call
СообщениеДобавлено: Сб июл 31, 2010 4:38 pm 
Не в сети
Kernel Developer
Аватара пользователя

Зарегистрирован: Пт авг 14, 2009 1:46 am
Сообщения: 1292
Serge писал(а):
art_zh
Выносим ядро ?
Код:
xor esp, esp
sysenetr

1001-й (не самый разрушительный) способ преднамеренного членовредительства...
Согласен, для десктопа не годится.

P.S. Хотя, в принципе, эта дырка затыкается в 2 хода.


Вернуться к началу
 Заголовок сообщения: Re: Fast System Call
СообщениеДобавлено: Сб июл 31, 2010 11:08 pm 
Не в сети
Kernel Developer

Зарегистрирован: Ср мар 08, 2006 6:25 pm
Сообщения: 3952
Всё равно ring 3 не прокатит. В режиме ядра может происходить переключение контекста со всеми вытекающими.


Вернуться к началу
 Заголовок сообщения: Re: Fast System Call
СообщениеДобавлено: Вс авг 01, 2010 2:13 am 
Не в сети
Kernel Developer
Аватара пользователя

Зарегистрирован: Пт авг 14, 2009 1:46 am
Сообщения: 1292
Ясно.
Нет никакого смысла резать живое ядро ради 30-40 тактов, тем более что на пнях всё равно не будет никакого выигрыша.
Спасибо Serge.

Но для AMDшного API я всё-таки его (syscall+SP3) попробую.

_________________
Узкий специалист подобен флюсу: полнота его - односторонняя.
Козьма Прутков


Вернуться к началу
 Заголовок сообщения: Re: Fast System Call
СообщениеДобавлено: Вт май 24, 2011 4:22 pm 
Не в сети
Kernel Developer
Аватара пользователя

Зарегистрирован: Пт авг 14, 2009 1:46 am
Сообщения: 1292
Внимание!
1) Начиная с #1937 отменена официальная поддержка инструкций syscall и sysenter для вызова API-функций ядра.
2) В ближайшее время эти инструкции будут удалены из всех программ репозитория (кроме /programs/develop/fast_call_test ) и заменены на int40h.
3) Старые обработчики syscall- и sysenter-вызовов оставлены в ядре до 1 июля 2011г.
4) После 01/07/11 нормальная работа старого кода с новыми версиями ядра не гарантируется.
5) Просьба к разработчикам: проверьте свой код и внесите соответствующие изменения в свои FTP-ресурсы.

Attention!
1) Since #1937 the kernel access via syscall and sysenter instructions is discontinued.
2) All the repository sources will be carefully inspected to replace these instructions with the standard int40h.
3) The current entry points of syscall and sysenter are kept in the kernel till the 1st of July, 2011
4) After 01/07/2011 the old code might not be guaranteed to work with the newer kernels.
5) Dear developers, please check your code and upload your FTPs with the fresher sources.


Вернуться к началу
 Заголовок сообщения: Re: Fast System Call
СообщениеДобавлено: Вт май 24, 2011 5:02 pm 
Не в сети
Kernel Developer

Зарегистрирован: Ср мар 08, 2006 6:25 pm
Сообщения: 3952
Может не стоит так торопиться ? Продлить переходный период и выпустить в конце официальный дистрибутив как новую точку отсчёта.
И мнение остальных неплохо узнать.


Вернуться к началу
 Заголовок сообщения: Re: Fast System Call
СообщениеДобавлено: Вт май 24, 2011 7:20 pm 
Не в сети
Kernel Developer
Аватара пользователя

Зарегистрирован: Пт авг 14, 2009 1:46 am
Сообщения: 1292
Serge
Пока народ перед фактом не поставишь - никто и не почешется.
По-моему, 6 недель - вполне приличный срок. Тем более что я не собираюсь сразу же после этого ядро кромсать назло всем.
Всего лишь гарантирую, что до июля все будет как и раньше.
И внимательно слушаю чужие мнения.


Вернуться к началу
 Заголовок сообщения: Re: Fast System Call
СообщениеДобавлено: Вт май 24, 2011 10:25 pm 
Не в сети
Moderator

Зарегистрирован: Чт апр 08, 2010 8:11 pm
Сообщения: 269
Если система станет ещё более быстрой и компактной, то я только за, удаление не нужного.


Вернуться к началу
 Заголовок сообщения: Re: Fast System Call
СообщениеДобавлено: Ср май 25, 2011 2:16 am 
Не в сети
Kernel Developer
Аватара пользователя

Зарегистрирован: Пт авг 14, 2009 1:46 am
Сообщения: 1292
popovpa
:? быстрее не станет.
Можно сэкономить ~1% кода, но это только на новых машинах, где вся система со двумя десятками процессов занимает ~1% памяти.

Главный смысл -
признание эксперимента по сабжу неудачным;
возврат mcall-API на единообразный int40h;
и освобождение "быстрых" переходов для узкоспециализированных API-сервисов, оптимизированных под эти переходы.

Новые API-функции и их формат надо обсуждать отдельно.
Сейчас очевидно, что они могут появиться только когда mcall вернется на int40h, или никогда.


Вернуться к началу
 Заголовок сообщения: Re: Fast System Call
СообщениеДобавлено: Ср май 25, 2011 7:55 am 
Я может плохо соображаю, но зачем трогать Trunk?
Какая экономия в размерах получится?
Люди старались делали и внезапно "Давайте отрежем Сусанину ногу...".

С другой стороны я не пользовался быстрыми вызовами ни разу, но наличие макроса mcall позволяет делать автоматическую сборку, с указанным типом вызова, так что из-за чего весь сыр-бор мне совершенно не понятно.


Вернуться к началу
   
 Заголовок сообщения: Ликбез
СообщениеДобавлено: Ср май 25, 2011 12:56 pm 
Не в сети
Kernel Developer
Аватара пользователя

Зарегистрирован: Пт авг 14, 2009 1:46 am
Сообщения: 1292
(вопрос_из_ЛС) писал(а):
Объясните в чём тогда выгода в переделке всего когда на int 0x40? Я просто в системном программировании полный ноль. Может подскажите что почитать, что бы не объяснять. Или в двух словах на колбасе.

Пользовательские программы крутятся в 3-м кольце, им доступ к критическим системным ресурсам запрещен. Когда надо - приложение посылает ядру API-запрос и диспетчер системных вызовов (core/syscall.inc) его обслуживает. Важно, что сам диспетчер работает в привилегированном 0-кольце, и поэтому приложения должны как-то к нему достучаться.

Классический метод - это вызов программного прерывания. Твоя программа может содержать инструкцию int NN, где NN- это номер нужного прерывания. Операционная система хранит таблицу для 256 прерываний, и некоторые из них могут быть использованы для вызова системных сервисов.

int40h - это стандартная менуэтовская точка входа в ядро. Она передает управление на метку i40: из core/syscall.inc
Очень простой и гибкий метод, только медленный (около 400 тактов тратится на вход-выход) и использует очень специфичный mcall-метод передачи параметров (в регистрах)

В этом сабже народ попробовал использовать более быстрые инструкции для вызова сисфункций - sysenter и syscall. Красиво и с дружно поработали, но вышел пшик: ускорение оказалось очень незначительным, а программы начали заметно раздуваться в размере. А все потому что преимущества "быстрых" вызовов были сведены к нулю из-за
1) эмуляции менуэтовского метода передачи параметров, и
2) громоздкого переключения контекста при входе в Ring0 - как при выполнении инструкции int.

Вроде бы решение лежит на поверхности: фиг с ними с mcall-вызовами, их уже никакие оптимизации не улучшат.
Давайте их оставим как были, на int40h, а "быстрые" вызовы будет проводить по-быстрому, без лишних плясок с бубном.
Чтобы узнать время или прочитать цвет точки на экране - вовсе не обязательно переключаться в стек ядра!

Но для этого надо сначала восстановить статус-кво и отменить эмуляцию int40h через syscall/sysener. Иначе новый сервис будет конфликтовать со старым кодом. Я изменил макросы mcall везде, где они встречались в транке. Теперь он генерит только int40h. Я предупредил, что уберу syscall_entry и sysenter_entry из ядра. Если мало 6 недель - подождем 6 месяцев или 6 лет, но решение надо принимать сейчас.

Mario писал(а):
С другой стороны я не пользовался быстрыми вызовами ни разу, но...
CleverMouse писал(а):
Ну, я быстрые вызовы тоже не использую.
Serge писал(а):
Быстрые вызовы дают слишком мизерные улучшения.
Diamond писал(а):
1) Происходит раздувание программ.
2)3) Происходит ненужное раздувание программ.
4) Происходит лишнее раздувание программ.
5) Теряется совместимость.
6) Наличествуют теневые эффекты.
Heavyiron писал(а):
В принципе, я согласен с тем, что быстрый вызов нужен не везде, но теперь менять все назад... 1) самому как-то не хочется; 2) учитывая объем работы, не думаю, что кто-то другой за это возьмется


Вернуться к началу
 Заголовок сообщения: Re: Fast System Call
СообщениеДобавлено: Ср май 25, 2011 1:31 pm 
art_zh
Мой вопрос собственно относился к тому зачем ломать, если при условной компиляции подставляется int 0x40 и никакого раздутия на уровне приложения. По крайней мере в официальном дистрибутиве собрано так.


Вернуться к началу
   
 Заголовок сообщения: Re: Fast System Call
СообщениеДобавлено: Ср май 25, 2011 1:40 pm 
Не в сети
Kernel Developer
Аватара пользователя

Зарегистрирован: Пт авг 14, 2009 1:46 am
Сообщения: 1292
У тебя компилится int40, а у сотен юзеров, которые скачивают транк раз в месяц и подставляют в автосборке "p6" или "k6" - генерится совсем другой код.
И надо этот код сейчас вернуть на int40, чтобы у них не было проблем с новыми версиями ядра в ближайшем будущем.


Вернуться к началу
Показать сообщения за:  Поле сортировки  
Начать новую тему  Ответить на тему  [ 145 сообщений ]  На страницу Пред. 16 7 8 9 10 След.

Часовой пояс: UTC+03:00


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и 1 гость


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
Создано на основе phpBB® Forum Software © phpBB Limited
Русская поддержка phpBB