Board.KolibriOS.org

А, вон ты про что.
а сейчас, стало быть, мышь таки-замирает на целых 200мс?
ну это некрупная фигня, стрелку можно отрисовывать и по основному таймерному прерыванию, не меняя контекста.

art_zh wrote:а сейчас, стало быть, мышь таки-замирает на целых 200мс

Время не считал, больше-меньше, но если запустишь пару-тройку обжор, то вот он WARP двигатель во всей красе скачущий курсор проявит себя.

art_zh wrote:ну это некрупная фигня, стрелку можно отрисовывать и по основному таймерному прерыванию, не меняя контекста.

Вот этого делать как раз нежелательно, мы в свое время с Сергеем это обсуждали. Обработчик таймера должен занимать минимум времени по вполне объективным причинам.

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

Если нужен длинный квант, надо добавить две переменные в APPDATA, кол-во тиков в кванте и countdown счетчик тиков и делать декремент в irq0. Соответственно после после переключения задачи обновляем счётчик и по новой.

Как насчет перемещения указателя курсора?

А для этого уже нужен планировщик с приоритетами. Сейчас у нас кооперативная коммунистическая диета. Все приложения кушают часто, но по-малу. Если менять длительность кванта и частоту переключения задач, надо вызывать планировщик после каждого обработчика irq.

Serge wrote:А для этого уже нужен планировщик с приоритетами. Сейчас у нас кооперативная коммунистическая диета. Все приложения кушают часто, но по-малу. Если менять длительность кванта и частоту переключения задач, надо вызывать планировщик после каждого обработчика irq.

Spoiler:

Mario_r4 wrote:традиция у нас такая каждый год мы собираемся чтобы обсудить подробности реализации: буфера обмена, таймера и загрузчика ОС...

Ага. Любое изменение в одной части кода потребует изменений в других частях.

Mario
Обещанный макет квантового дегенератора: отгрызает 1.6млн тактов (=1мс на моем проце) от текущего кванта

т.е. в твоей версии планировщика - приватизирует (безвоздмездно!) время следующего "длинного" процесса.

поставь время задержки 9миллисекунд, а потом запусти своего обжору.
и шо, это таки-не багофича?

art_zh wrote:MarioОбещанный макет квантового дегенератора:

А на предыдущем варианте значит все замечательно?
Ты приведи пример реального приложения. А то извратных приложений много можно насочинять - на то у тебя и хитрый изворотливы мозг.
Багрепортов об изменении работы существующих приложений не было пока.

З.Ы. Diamond вообще вирус написал - мне чего теперь стреляться? Я не офицер чтобы стреляться.

Старый планировщик ГАРАНТИРОВАЛ ЛЮБОМУ приложению ЗАКОННЫЕ 10мс времени.

art_zh wrote:Старый планировщик ГАРАНТИРОВАЛ ЛЮБОМУ приложению ЗАКОННЫЕ 10мс времени.

Значит сриншоты я в Gimp нарисовал?

Твои скриншоты подтверждают выполнение этой гарантии: времяёмкие приложения получали свои 10мс чистого времени, а если кому повезет - тогда почти 20мс.

А слабо выложить скриншоты с новым планировщиком и парой дегенератор+обжора ?

art_zh wrote:А слабо выложить скриншоты с новым планировщиком и парой дегенератор+обжора ?

Не слабо, но времени не хватает. Как будет время посмотрю и заскриню.
Однако 20 мс отдавать это неправильно, при заявленном равноправии.

art_zh wrote:Mario
Обещанный макет квантового дегенератора:

Code: Select all

  
  use32             
  org    0         
  db     'MENUET01'  
  dd     1, START,  VOILA    
  dd     0x1000, 0x1000,  0,  0         
 
START:
  rdtsc
  add eax, 1600000 ; = 1миллисекунда
  jnc @f
  inc edx
@@:
  mov [keep_eax], eax
  mov [keep_edx], edx
wait_1ms:
  rdtsc
  cmp edx, [keep_edx]
  jb wait_1ms
  cmp eax, [keep_eax]
  jb wait_1ms

  mov eax, 68
  mov ebx, 1
  int 40h
  jmp START   

keep_eax  dd 0
keep_edx  dd 0
VOILA:

отгрызает 1.6млн тактов (=1мс на моем проце) от текущего кванта

т.е. в твоей версии планировщика - приватизирует (безвоздмездно!) время следующего "длинного" процесса.

поставь время задержки 9миллисекунд, а потом запусти своего обжору.
и шо, это таки-не багофича?

Есть впрос: "А вот 'inc edx', edx от какого значения инкременируется?"
Да и значение "1600000" - это всего лишь частное значение какой-то частной машины.
По первому вопросу, я знаю, что возвращает "rdtsc".

меняется на

art_zh, в случае выдуманного примера становится хуже, в типичных случаях становится лучше. Всем хорошо сделать нельзя, значит, нужно делать хорошо в типичном случае. Приложения, отжирающие столько времени, сколько им дали, типичны и встречаются на каждом шагу - те же демки - а приложений, действующих подобно viewtopic.php?p=48637#p48637 , на практике не встречается. Выбор очевиден.

Mario
Это воровать чужие миллисекунды неправильно.
А чем плох +10мс бонус?
Это ведь сэкономленное время, добровольно предоставленное (именно как бонус!) вежливыми предыдущими процессами.

Artyom
инкремент к текущему edx.
сам edx еще очень нескоро переполнится

Serge
так на 2 байта короче.

CleverMouse et al.
Невыдуманные примеры: традиционно-вежливые RT-процессы (в т.ч. неопределенно-длинные: диски, сеть и звук).