Board.KolibriOS.org

Official KolibriOS board
It is currently Sun Oct 24, 2021 4:32 pm

All times are UTC+03:00




Post new topic  Reply to topic  [ 145 posts ]  Go to page Previous 16 7 8 9 10
Author Message
 Post subject: Re: Fast System Call
PostPosted: Wed May 25, 2011 2:16 am 
Offline
Kernel Developer
User avatar

Joined: Fri Aug 14, 2009 1:46 am
Posts: 1449
popovpa
:? быстрее не станет.
Можно сэкономить ~1% кода, но это только на новых машинах, где вся система со двумя десятками процессов занимает ~1% памяти.

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

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


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

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


Top
   
 Post subject: Ликбез
PostPosted: Wed May 25, 2011 12:56 pm 
Offline
Kernel Developer
User avatar

Joined: Fri Aug 14, 2009 1:46 am
Posts: 1449
(вопрос_из_ЛС) wrote:
Объясните в чём тогда выгода в переделке всего когда на 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 wrote:
С другой стороны я не пользовался быстрыми вызовами ни разу, но...
CleverMouse wrote:
Ну, я быстрые вызовы тоже не использую.
Serge wrote:
Быстрые вызовы дают слишком мизерные улучшения.
Diamond wrote:
1) Происходит раздувание программ.
2)3) Происходит ненужное раздувание программ.
4) Происходит лишнее раздувание программ.
5) Теряется совместимость.
6) Наличествуют теневые эффекты.
Heavyiron wrote:
В принципе, я согласен с тем, что быстрый вызов нужен не везде, но теперь менять все назад... 1) самому как-то не хочется; 2) учитывая объем работы, не думаю, что кто-то другой за это возьмется


Top
   
 Post subject: Re: Fast System Call
PostPosted: Wed May 25, 2011 1:31 pm 
art_zh
Мой вопрос собственно относился к тому зачем ломать, если при условной компиляции подставляется int 0x40 и никакого раздутия на уровне приложения. По крайней мере в официальном дистрибутиве собрано так.


Top
   
 Post subject: Re: Fast System Call
PostPosted: Wed May 25, 2011 1:40 pm 
Offline
Kernel Developer
User avatar

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


Top
   
 Post subject: Re: Fast System Call
PostPosted: Wed May 25, 2011 1:59 pm 
Насчет сотен юзеров ты конечно оптимистично погорячился, но если уж считаешь что второй раз мартышкин труд будет полезен, то я тогда не возражаю. :mrgreen:


Top
   
 Post subject: Re: Fast System Call
PostPosted: Mon Sep 05, 2011 10:10 am 
Offline
Kernel Developer
User avatar

Joined: Mon Mar 20, 2006 10:44 am
Posts: 558
И упало каменное слово
На мою еще живую грудь.
...

По моему можно было просто поправить автосборку, что бы у всех собиралось под int40.
> генерится совсем другой код.
какие проблемы с этим возникали?
Я понял что идеи две:
1. Сэкономить место
2. Использовать SYSCALL/SYSENTER с другими параметрами нежели int40. - но тут получим только раздувание кода.

Таки в чем идея? В принципе код писался с целью эксперимента и мне его не жалко, только я:
1. Не вижу мотивированных причин для его удаления
2. Этот код мог послужить кому то хорошим примером, для дальнейшего развития системы, его удаление заставит переписывать подобный код в будущем с нуля.


Top
   
 Post subject: Re: Fast System Call
PostPosted: Mon Sep 05, 2011 10:55 am 
Offline
Kernel Developer
User avatar

Joined: Fri Aug 14, 2009 1:46 am
Posts: 1449
Ghost
Идея одна - ускорить отработку некоторых новых системных вызовов не на 30%, а в 3 раза, как положено.

Очень много времени занимает переключение стека и эмуляция int40.

Ну и фиг с этой эмуляцией. Давай вызывать старые сисфункции только через int40,
и добавим новую группу (быстрых) вызовов через syscall (с эмуляцией через int41 для тех, у кого этого нет).

Вот и вся идея.

PS
Quote:
И упало каменное слово
На мою еще живую грудь.
Это стихи надломленной женщины бальзаковского возраста. Тебе они совсем не подходят.


Top
   
 Post subject: Re: Fast System Call
PostPosted: Mon Sep 05, 2011 12:10 pm 
Offline
Kernel Developer
User avatar

Joined: Mon Mar 20, 2006 10:44 am
Posts: 558
Стихи цитировал к безоговорочному решению выбросить код.
Я отсутствовал продолжительное время, но сдается мне что вешать на быстрые вызовы нечего ) Расчищать место для будущей постройки хорошо, но по моему её ещё даже в планах нет?


Top
   
 Post subject: Re: Fast System Call
PostPosted: Mon Sep 05, 2011 12:21 pm 
Offline
Kernel Developer
User avatar

Joined: Fri Aug 14, 2009 1:46 am
Posts: 1449
Ghost wrote:
Я отсутствовал продолжительное время, но сдается мне что вешать на быстрые вызовы нечего ) Расчищать место для будущей постройки хорошо, но по моему её ещё даже в планах нет?

... Этот код мог послужить кому то хорошим примером, для дальнейшего развития системы, его удаление заставит переписывать подобный код в будущем с нуля.

Посмотри svn//kernel/branches/Kolibri-A/trunk/core/syscall.inc
твой код работает просто замечательно! и в таком виде он раскрывается на 100%, а не эмулирует дремучее программное прерывание.

"Длинный" системный сервис на syscall переносить нет смысла, зато для операций типа rdmsr или putpixel это - именно то что надо.


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 145 posts ]  Go to page Previous 16 7 8 9 10

All times are UTC+03:00


Who is online

Users browsing this forum: No registered users and 3 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Limited