| 1.1, TTT (?), 13:34, 10/07/2007 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
что-то у меня не сходится, поясните невежде
сказано:
> Единица планирования времени в CFS фиксирована - наносекунда
на 3GHz процессоре за 1-у наносекунду проходит 3 такта, учитывая что даже чтение из памяти может занять несколько десятков тактов, а за один такт точно не делается больше одной опарации ( во всяком случае на х86 ), то как можно планировать каждую наносекунду? | | |
| |
| 2.3, alcohollica (?), 15:39, 10/07/2007 [^] [^^] [^^^] [ответить]
| +/– | |
я так понимаю, это для того, чтобы оставить задел на будущее - серастет сейчас в основном не частота процессоров, а количество ядер. | | |
| |
| 3.4, alcohollica (?), 15:43, 10/07/2007 [^] [^^] [^^^] [ответить]
| +/– |
клавиатура сглючила. :)
так вот. в основном растет не частота процессоров, а количество ядер. И видимо легче отталкиваться от временного промежутка, чем от частоты.
Хотя все это конечно ИМХО | | |
|
| 2.5, Aquarius (?), 19:39, 10/07/2007 [^] [^^] [^^^] [ответить]
| +/– |
А кто что-то сказал, про конкретный порядок количества, измеряемого этой единицей измерения?
Кто сказал, что есть возможность, к примеру, задать 3 наносекунды для длительности чего-либо?
>> Единица планирования времени в CFS фиксирована - наносекунда
>на 3GHz процессоре за 1-у наносекунду проходит 3 такта, учитывая что даже
>чтение из памяти может занять несколько десятков тактов, а за один
>такт точно не делается больше одной опарации ( во всяком случае
>на х86 ), то как можно планировать каждую наносекунду?
| | |
| 2.6, serg1224 (?), 00:10, 11/07/2007 [^] [^^] [^^^] [ответить]
| +/– |
 > ,,, а за один такт точно не делается больше одной опарации...
Да, вроде, давно уже делается. На Интелах, по крайней мере. | | |
| 2.7, _Nick_ (??), 07:15, 11/07/2007 [^] [^^] [^^^] [ответить]
| +/– |
 > как можно планировать каждую наносекунду?
легко.
вообще, разрешающая способность шедулера ограничиваеться разрешением таймера, прерываниями которого могут ограничиваться слайсы работы процессов.
т.е. неважно сколько инструкций выполнил процесс за отведенный ему слайс в минимум одну наносекудну: хоть 1, хоть 3, хоть 500 (ну, через пиццот лет :) - при прерывании таймера управление может быть передано другому процессу. | | |
| |
| 3.8, _Nick_ (??), 07:20, 11/07/2007 [^] [^^] [^^^] [ответить]
| +/– |
кстати, выражения "Единица планирования времени в CFS фиксирована - наносекунда"
и "как можно планировать каждую наносекунду?" не приведены к общему знаменателю :)
т.е. говорят о разных вещах.
Те. первая утверждает, что результатом работы шедулера будет _количество_ наносекунд, выданное какому-либо процессу.
Вторая робко надееться, что каждая наносекунда работы процессора будет точно расписана :)
Ессьно, этого не будет. Сам шедулер _может_ работать больше наносекунды (если конечно нужно и частота проца достаточно низка). Просто на его выходе будет цыфра в наносекундах. | | |
|
|
| 1.2, DEC (??), 13:55, 10/07/2007 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
n CFS this fairness imbalance is expressed and tracked via the per-task p->wait_runtime (nanosec-unit) value. "wait_runtime" is the amount of time the task should now run on the CPU for it to become completely fair and balanced.
Wrong translation | | |
| 1.9, Denis (??), 12:51, 11/07/2007 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 Вот интересно - его намернво заменять, или можно будет выбрать между несколькими вариантами?
И как бы тоже крайне интересно - почему все упираются в наносекунду?
Это просто точность шедулера наносекунда. А задания которые будут находиться в состоянии ожидания, состояния выполнения,обработчики нижних и верхних половин и програмные прерывания будут более рационально использовать время, пусть даже одного ядра. | | |
| 1.10, Denis (??), 12:54, 11/07/2007 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
А кто вообще писал новость?
На rbtree перешли уже давно, с ядра так эдак 2.6.10, об этом Роберт лав писал в книжке. Или у разработчиков ядра уже дежавю :-)
| | |
| 1.11, Ivan (??), 13:35, 11/07/2007 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 дополните и поправте если я заблуждаюсь, преключение контекста задачи
1 чем больше за единицу времени тем лучше? (плавность перехода) и хреново меньше попаданий в кешь ЦПУ растут задержки при обращении к памяти общее снижение производительности
2 чем меньше за единицу времени тем лучше? | | |
| |
| 2.12, _Nick_ (??), 00:22, 13/07/2007 [^] [^^] [^^^] [ответить]
| +/– |
>дополните и поправте если я заблуждаюсь, преключение контекста задачи
>1 чем больше за единицу времени тем лучше? (плавность перехода) и
>хреново меньше попаданий в кешь ЦПУ растут задержки при обращении к
>памяти общее снижение производительности
>
>2 чем меньше за единицу времени тем лучше?
тут все просто: переключение - это уже работа, на которую уходит время.
Ну и про кеш ты правильно сказал.
Больше переключений - сильнее иллюзия многозадачности и выше скорость реакции.
Но факт фактом: скорость и интерактивность - на разных чашах весов. | | |
| 2.13, Denis (??), 08:31, 13/07/2007 [^] [^^] [^^^] [ответить]
| +/– |
1) - не совсем так, все зависит от систему (сервер, рабочая станция). По принципу мышления, если за кэшем не следить, то падает производительность, но ядро следит за кэшем и поддерживает его в актуальном состоянии + у проца есть предсказание переходов и ветвлений. Если сравнить скорость обмена с памятью и кэшем 2 уровня - скорость раза в два меньше.
2) - в планировщике задач это оптимизированно, и перестаривается в процессе работы. | | |
|
| 1.14, Ne01eX (??), 09:40, 13/07/2007 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
c CFS понятно, а что с SD (бывший RSDL) будет? Более правильным решением было бы конечно включению в основную ветку ядра обоих новых планировщиков и дать юзверю (то есть мне) уже выбрать... А вообще, - хорошая тенденция. | | |
|
