два года?
не путай тёплоё с мягким
> sleep mutexes
это то же самое, что семафоры в линуксе (были всегда, кажется) ?
> interrupt kernel threads
гугл говорит, что обработчики делятся на FAST (которым треда не дают) и остальные, которые выполняются в контексте треда (то-то ты удивлялся, что линукс даже на помоечном железе может >100k int/sec обрабатывать и ещё для процессов остаётся время
)
аналогично (но не очень?) в линуксе очень давно обработчики состоят из top half (которая может быть совсем маленькой) и bottom half (которая может делать всю работу)
в статье же говорится, что RT-патч отменяет спинлоки _совсем_, и переносит _всю_ обработку прерываний в контекст тредов (говорят, кстати, в winnt так было с рождения, с соответствующим результатом в плане производительности)
и всё ради реального времени, причём даже не гарантированного
> sleep mutexes
это то же самое, что семафоры в линуксе (были всегда, кажется) ?
> interrupt kernel threads
гугл говорит, что обработчики делятся на FAST (которым треда не дают) и остальные, которые выполняются в контексте треда (то-то ты удивлялся, что линукс даже на помоечном железе может >100k int/sec обрабатывать и ещё для процессов остаётся время
)аналогично (но не очень?) в линуксе очень давно обработчики состоят из top half (которая может быть совсем маленькой) и bottom half (которая может делать всю работу)
в статье же говорится, что RT-патч отменяет спинлоки _совсем_, и переносит _всю_ обработку прерываний в контекст тредов (говорят, кстати, в winnt так было с рождения, с соответствующим результатом в плане производительности)
и всё ради реального времени, причём даже не гарантированного
>говорят, кстати, в winnt так было с рождения, с соответствующим результатом в плане производительности
Ээээ
Тебя обманули.
Ну либо это в раннем младенчестве убрали.
Ээээ
Тебя обманули.
Ну либо это в раннем младенчестве убрали.
ну может и обманули, я не проверял
Не путай теплое с мягким.
> > sleep mutexes
> это то же самое, что семафоры в линуксе (были всегда, кажется) ?
Нет, не то же самое.
> гугл говорит, что обработчики делятся на FAST (которым треда не дают) и остальные, которые выполняются в контексте треда
Плевать на гугл. Покажи обработчики прерываний в 'ps axl' в Linux. Речь не о контексте треда. Речь о наличии треда для обработки каждого прерывания.
> (то-то ты удивлялся, что линукс даже на помоечном железе может >100k int/sec обрабатывать и ещё для процессов остаётся время )
Я такого не помню. Ни факта такого, ни того что бы я удивлялся.
> > sleep mutexes
> это то же самое, что семафоры в линуксе (были всегда, кажется) ?
Нет, не то же самое.
> гугл говорит, что обработчики делятся на FAST (которым треда не дают) и остальные, которые выполняются в контексте треда
Плевать на гугл. Покажи обработчики прерываний в 'ps axl' в Linux. Речь не о контексте треда. Речь о наличии треда для обработки каждого прерывания.
> (то-то ты удивлялся, что линукс даже на помоечном железе может >100k int/sec обрабатывать и ещё для процессов остаётся время )
Я такого не помню. Ни факта такого, ни того что бы я удивлялся.
> Нет, не то же самое.
В чём разница, вкратце?
> Покажи обработчики прерываний в 'ps axl' в Linux.
ksoftirqd_*
> Речь о наличии треда для обработки каждого прерывания.
Нафиг надо?
> Ни факта такого, ни того что бы я удивлялся.
Сейчас погрепаю почту, это не быстро - много её.
В чём разница, вкратце?
> Покажи обработчики прерываний в 'ps axl' в Linux.
ksoftirqd_*
> Речь о наличии треда для обработки каждого прерывания.
Нафиг надо?
> Ни факта такого, ни того что бы я удивлялся.
Сейчас погрепаю почту, это не быстро - много её.
> В чём разница, вкратце?
sleep mutex это мьютекс, то есть совсем не семафор. Под концепцией мьютекса я понимаю, то что называется мьютексом в POSIX threads. Под концепцией семафора я понимаю опять же POSIX семафоры.
Или семафоры в ядре Linux не являются концептуальным аналогами POSIX семафоров?
> ksoftirqd_*
Их два (на phoenix).
> > Речь о наличии треда для обработки каждого прерывания.
> Нафиг надо?
Это уже другой вопрос. На него я точно ответить не смогу (ниже попытаюсь). Вообще данным тредом я хотел проконстантировать сабж, на зло товарищу ПЖ.
Наверное наличие треда для каждого прерывания даёт возможность более тонко скедулить. Любой из этих тредов может заблокироваться на чём-то, и другие прерывания при этом будут обрабатываться.
sleep mutex это мьютекс, то есть совсем не семафор. Под концепцией мьютекса я понимаю, то что называется мьютексом в POSIX threads. Под концепцией семафора я понимаю опять же POSIX семафоры.
Или семафоры в ядре Linux не являются концептуальным аналогами POSIX семафоров?
> ksoftirqd_*
Их два (на phoenix).
> > Речь о наличии треда для обработки каждого прерывания.
> Нафиг надо?
Это уже другой вопрос. На него я точно ответить не смогу (ниже попытаюсь). Вообще данным тредом я хотел проконстантировать сабж, на зло товарищу ПЖ.
Наверное наличие треда для каждого прерывания даёт возможность более тонко скедулить. Любой из этих тредов может заблокироваться на чём-то, и другие прерывания при этом будут обрабатываться.
> sleep mutex это мьютекс, то есть совсем не семафор.
семафор можно использовать как мьютекс; я с POSIX threads не сильно знаком, в ядре наверняка другие семафоры
в общем, тред может сказать down(&sem выполнить код, потом up(&sem); другие треды будут спать на down пока первый не сделает up
mutex самый настоящий
> > ksoftirqd_*
> Их два (на phoenix).
На каждый процессор по одному.
Драйвер может завести тред для себя, и сразу отдавать в него прерывания, если захочет. Учитывая, что устройства могут разделять прерывание, это полезнее, чем тред, привязанный к IRQ.
> на зло товарищу ПЖ
ну-ну
> Любой из этих тредов может заблокироваться на чём-то, и другие
> прерывания при этом будут обрабатываться.
А как решается вопрос с общим прерыванием для нескольких различных устройств?
Письмо, где ты удивляешься скорости обработки прерываний в Linux, я нашёл. Кидать?
семафор можно использовать как мьютекс; я с POSIX threads не сильно знаком, в ядре наверняка другие семафоры
в общем, тред может сказать down(&sem выполнить код, потом up(&sem); другие треды будут спать на down пока первый не сделает up
mutex самый настоящий
> > ksoftirqd_*
> Их два (на phoenix).
На каждый процессор по одному.
Драйвер может завести тред для себя, и сразу отдавать в него прерывания, если захочет. Учитывая, что устройства могут разделять прерывание, это полезнее, чем тред, привязанный к IRQ.
> на зло товарищу ПЖ
ну-ну
> Любой из этих тредов может заблокироваться на чём-то, и другие
> прерывания при этом будут обрабатываться.
А как решается вопрос с общим прерыванием для нескольких различных устройств?
Письмо, где ты удивляешься скорости обработки прерываний в Linux, я нашёл. Кидать?
в общем, тред может сказать down(&sem выполнить код, потом up(&sem); другие треды будут спать на down пока первый не сделает upУ него есть понятие хозяина? Можно ли сказать, что именно этот тред сейчас держит семафор? Если нет, то это не мьютекс.
Драйвер может завести тред для себя, и сразу отдавать в него прерывания, если захочет. Учитывая, что устройства могут разделять прерывание, это полезнее, чем тред, привязанный к IRQ.Что значит "отдавать"? Прерывание при этом сможет выполниться еще раз для другого устройства на нём же.
А как решается вопрос с общим прерыванием для нескольких различных устройств?Никак. Как его можно решить?
Письмо, где ты удивляешься скорости обработки прерываний в Linux, я нашёл. Кидать?Кидай.
Кстати еще одно преимущество я вижу у тредов для прерываний - профилирование. В top можно смотреть какое прерывание сколько ест.
>Что значит "отдавать"?
Это значит делегировать выполнение прерывания этому треду. Для этого куда-то записываются все данные прерывания и отдаются этому треду. При этом достигается наименьшее нахождение в контексте прерывания.
Это значит делегировать выполнение прерывания этому треду. Для этого куда-то записываются все данные прерывания и отдаются этому треду. При этом достигается наименьшее нахождение в контексте прерывания.
>Никак. Как его можно решить?
У вас там чо, правда не бывает shared irqs?
У вас там чо, правда не бывает shared irqs?
> У вас там чо, правда не бывает shared irqs?
Именно о них и речь, если ты не понял.
Именно о них и речь, если ты не понял.
Это значит делегировать выполнение прерывания этому треду. Для этого куда-то записываются все данные прерывания и отдаются этому треду. При этом достигается наименьшее нахождение в контексте прерывания.Разве это поможет решить проблему с тем, что пока выполняется прерывание от этого устройства, прерывание от второго устройства, висящего на этом же irq будет ждать.
>Именно о них и речь, если ты не понял.
Я не понял, что означает фраза:
>Никак. Как его можно решить?
Ты не мог бы изъясняться менее иносказательно?
Я не понял, что означает фраза:
>Никак. Как его можно решить?
Ты не мог бы изъясняться менее иносказательно?
Я не понял, что означает фразаНаверное я правильно понял Володю с полуслова. Думаю он имел в виду, что есть проблема в том, что не получается два устройства на одном прерывании обслуживать так же быстро как если бы они были на разных.
Нет конечно. Но при этом сам обработчик прерывания ждать не будет. Он просто положит данные в очередь и выйдет.
> Если нет, то это не мьютекс.
Странное у тебя определение мьютекса, нас другому учили.
> Что значит "отдавать"?
Приходит прерывание, драйвер тут же будит тред-обработчик, который делает потом всю работу. Соответственно, решается проблема с общим прерыванием (насколько это вообще можно сделать).
> Кстати еще одно преимущество я вижу у тредов для прерываний
> - профилирование. В top можно смотреть какое прерывание сколько ест.
Для профилирования есть более общие механизмы, которые не только по тредам умеют смотреть, а по функциям и инструкциям.
> Кидай.
Там дальше ты походу так и не поверил в 100kints/sec.
А ведь всё без честно, в /proc/interrupts настоящие счётчики прерываний.
Интересно, что будет с этим RT-патчем, в статье пишут, что нормальных бенчмарков ещё не делали.
Странное у тебя определение мьютекса, нас другому учили.
> Что значит "отдавать"?
Приходит прерывание, драйвер тут же будит тред-обработчик, который делает потом всю работу. Соответственно, решается проблема с общим прерыванием (насколько это вообще можно сделать).
> Кстати еще одно преимущество я вижу у тредов для прерываний
> - профилирование. В top можно смотреть какое прерывание сколько ест.
Для профилирования есть более общие механизмы, которые не только по тредам умеют смотреть, а по функциям и инструкциям.
> Кидай.
Date: Mon, 17 Mar 2003 20:50:24 +0300
Subject: Re: [palisadesys.com: RE: polling for gigabit NICs]
From: 'Gleb Smirnoff' <cell.sick.ru>
To: "Vladimir B. Savkin" <sectorb.msk.ru>
[...]
V> В общем, тачка с Celeron 1200 Tualatin пропускает более 100kpps,
V> соответственно >100000int/sec, и ещё остаётся процессорного времени,
V> т.е. для wire-speed на fast ethernet нынче никакого поллинга и не надо.
V> Найду тачку послабее, буду на ней проверять :)
Неверится. Ты уверен что у тебя было 100kpps? Как ты их генерил?
Ни разу не слышал о работе роутера с >100000int/sec на сетевухах.
Люди пишут, что ложится на бок уже при 15000 прерываний от сетевух.
[...]
Там дальше ты походу так и не поверил в 100kints/sec.
А ведь всё без честно, в /proc/interrupts настоящие счётчики прерываний.
Интересно, что будет с этим RT-патчем, в статье пишут, что нормальных бенчмарков ещё не делали.
> Думаю он имел в виду, что есть проблема в том, что не получается два
> устройства на одном прерывании обслуживать так же быстро как если бы
> они были на разных.
Неа. Если выделять по треду на каждый IRQ, то если тред заснёт (на том же sleeping mutex то он заблокирует работу всех устройств, висящих на этом же IRQ. Понятно, что это не дело, так что эта проблема должна как-то решаться во FreeBSD.
> устройства на одном прерывании обслуживать так же быстро как если бы
> они были на разных.
Неа. Если выделять по треду на каждый IRQ, то если тред заснёт (на том же sleeping mutex то он заблокирует работу всех устройств, висящих на этом же IRQ. Понятно, что это не дело, так что эта проблема должна как-то решаться во FreeBSD.
http://www.google.ru/search?q=define%3Amutex
все найденные определения похожи, и ни одно не говорит, что нужно уметь узнавать владельца
все найденные определения похожи, и ни одно не говорит, что нужно уметь узнавать владельца
Нет конечно. Но при этом сам обработчик прерывания ждать не будет. Он просто положит данные в очередь и выйдет.Если он положит в очередь, а потом другой тред подберёт его, то это уже не будет быстрой обработкой прерывания. Кроме того, очереди еще требуют локинга, который дорого.
> Странное у тебя определение мьютекса, нас другому учили.
Не путай определение и свойство. Без свойства "хозяина", не может быть понятия "рекурсивное взятие мьютекса".
> Приходит прерывание, драйвер тут же будит тред-обработчик, который делает потом всю работу. Соответственно, решается проблема с общим прерыванием
> (насколько это вообще можно сделать).
Это не есть быстрая обработка. Проблема с общим прерыванием не решается. Под проблемой имеется в виду не то, что устройства должны просто работать, а то, что они должны работать так же быстро, как если бы были на одном прерывании.
> Там дальше ты походу так и не поверил в 100kints/sec.
Тогда не поверил, сейчас поверю. Я видел и больше. Только 1200 MHz не есть мусорное железо.
Не путай определение и свойство. Без свойства "хозяина", не может быть понятия "рекурсивное взятие мьютекса".
> Приходит прерывание, драйвер тут же будит тред-обработчик, который делает потом всю работу. Соответственно, решается проблема с общим прерыванием
> (насколько это вообще можно сделать).
Это не есть быстрая обработка. Проблема с общим прерыванием не решается. Под проблемой имеется в виду не то, что устройства должны просто работать, а то, что они должны работать так же быстро, как если бы были на одном прерывании.
> Там дальше ты походу так и не поверил в 100kints/sec.
Тогда не поверил, сейчас поверю. Я видел и больше. Только 1200 MHz не есть мусорное железо.
> Не путай определение и свойство.
Ты сказал, что если нет "хозяина", то это не мьютекс.
В других же источниках от мьютексов такого не требуется, а рекурсивность считается дополнительным, необязательным свойством.
> Только 1200 MHz не есть мусорное железо.
Эти процессоры были не в моде уже тогда, так же как PC100 SDRAM.
Ты сказал, что если нет "хозяина", то это не мьютекс.
В других же источниках от мьютексов такого не требуется, а рекурсивность считается дополнительным, необязательным свойством.
> Только 1200 MHz не есть мусорное железо.
Эти процессоры были не в моде уже тогда, так же как PC100 SDRAM.
> Если он положит в очередь, а потом другой тред подберёт его, то это уже не
> будет быстрой обработкой прерывания.
Ну да, в отдельном треде обрабатывать прерывания не так быстро, как "сразу". Нужно запускать планировщик, переключать контексты и т.д. Очередь, кстати не обязательна, как и блокировка в ней.
> будет быстрой обработкой прерывания.
Ну да, в отдельном треде обрабатывать прерывания не так быстро, как "сразу". Нужно запускать планировщик, переключать контексты и т.д. Очередь, кстати не обязательна, как и блокировка в ней.
>Если он положит в очередь, а потом другой тред подберёт его, то это уже не будет быстрой обработкой прерывания. Кроме того, очереди еще требуют локинга, который дорого.
При этом прерывание обработается наиболее быстро. Вот выполнится возможно немного медленнее.
При этом прерывание обработается наиболее быстро. Вот выполнится возможно немного медленнее.
Ты сказал, что если нет "хозяина", то это не мьютекс.Хорошо. Тогда давай определение мьютекса. Фраза "просто ищи в гугле" не катит.
В других же источниках от мьютексов такого не требуется, а рекурсивность считается дополнительным, необязательным свойством.
Первое определение из списка вполне подходит.
A primitive object that provides mutual exclusion between threads. A mutex is used cooperatively between threads to ensure that only one of the cooperating threads is allowed to access shared data or run certain application code at a time.
Операция lock cmxchg - мьютекс?
это не объект, а лишь одна из операций
Ты лучше скажи, каким образом FreeBSD избегает ситуации, когда обработчик прерывания засыпает и блокирует работу всех устройств, висящих на данном IRQ. Это основной вопрос треда.
> это не объект, а лишь одна из операций
То есть её аргумент - мьютекс. По твоему определению подходит.
То есть её аргумент - мьютекс. По твоему определению подходит.
Ты лучше скажи, каким образом FreeBSD избегает ситуации, когда обработчик прерывания засыпает и блокирует работу всех устройств, висящих на данном IRQ.Не знаю. Почитай исходники или книжки, если тебе интересно.
Это основной вопрос треда.В этом треде нет вопроса. В этом треде есть утверждение, что Linux собирается ввести два нововведения, которые есть в FreeBSD уже полтора года.
> То есть её аргумент - мьютекс. По твоему определению подходит.
Чтобы она стала мьютексом, необходим определённый протокол использования. Само по себе использование данной команды в каком-то
участке кода ещё не говорит о том, что присутствует мьютекс.
На одной такой операции мьютекс не сделать, нужны другие.
Чтобы она стала мьютексом, необходим определённый протокол использования. Само по себе использование данной команды в каком-то
участке кода ещё не говорит о том, что присутствует мьютекс.
На одной такой операции мьютекс не сделать, нужны другие.
> Почитай исходники или книжки, если тебе интересно.
Ок, ты не в курсе предмета обсуждения.
> В этом треде есть утверждение, что Linux собирается ввести два нововведения, которые есть в FreeBSD уже полтора года.
Утверждение неправильное, см. мой первый пост.
Слив засчитан.
Ок, ты не в курсе предмета обсуждения.
> В этом треде есть утверждение, что Linux собирается ввести два нововведения, которые есть в FreeBSD уже полтора года.
Утверждение неправильное, см. мой первый пост.
Слив засчитан.
>В этом треде нет вопроса. В этом треде есть утверждение, что Linux собирается ввести два нововведения, которые есть в FreeBSD уже полтора года.
Дружище, Инго свои патчи уже больше чем полтора года делает Другое дело что они не в mainline... Но есть они уже очень давно. Даже в 2.4 были.
Дружище, Инго свои патчи уже больше чем полтора года делает
Другое дело что они не в mainline... Но есть они уже очень давно. Даже в 2.4 были.Чтобы она стала мьютексом, необходим определённый протокол использования. Само по себе использование данной команды в каком-тоТаким образом твоё определение, приведённое, выше не подходит. Слив засчитан.
участке кода ещё не говорит о том, что присутствует мьютекс.
На одной такой операции мьютекс не сделать, нужны другие.
>Ок, ты не в курсе предмета обсуждения.
Я не в курсе поставленного тобой вопроса, который не укладывается в предмет обсуждения.
> Утверждение неправильное, см. мой первый пост.
Утверждение правильное.
а) preemptable mutexes были в FreeBSD 5.2
б) interrupt kernel threads были в FreeBSD 5.2
Я не в курсе поставленного тобой вопроса, который не укладывается в предмет обсуждения.
> Утверждение неправильное, см. мой первый пост.
Утверждение правильное.
а) preemptable mutexes были в FreeBSD 5.2
б) interrupt kernel threads были в FreeBSD 5.2
Определение подходит.
> A mutex is used cooperatively between threads
то есть должен существовать протокол использования, которому следуют треды
> A mutex is used cooperatively between threads
то есть должен существовать протокол использования, которому следуют треды
Утверждение неверное, так как в Linux аналоги существуют более двух лет.
> Определение подходит.
Оно не достаточно.
Оно не достаточно.
Для чего не достаточно?
Все остальные определения такие же.
Только ты придумал своё, неизвестно откуда взятое.
Все остальные определения такие же.
Только ты придумал своё, неизвестно откуда взятое.
> Утверждение неверное, так как в Linux аналоги существуют более двух лет.
Я понял, что тебя не убедить что это не так. Впрочем мне похуй. Пусть будет по-твоему. И тогда необходимость и актуальность новых наработок Молнара прекрасно укладываются вот в эту цитату:
Я понял, что тебя не убедить что это не так. Впрочем мне похуй. Пусть будет по-твоему. И тогда необходимость и актуальность новых наработок Молнара прекрасно укладываются вот в эту цитату:
Q26: а вот в линухе провалилась эпопея с XXX и её из главветки убрали...
A26: я с самого начала считал её неудачным схемным реЩением! да и не юзал никогда. мамой клянусь!
> и её из главветки убрали
пока что её там нет, так что цитата преждевременна
> Я понял, что тебя не убедить что это не так
Именно. И раз уж ты говоришь, что фичи для тебя не на первом и не на втором месте (к тому же такие несерьёзные то в следующий раз лучше бы о более важных вещах поговорить.
пока что её там нет, так что цитата преждевременна
> Я понял, что тебя не убедить что это не так
Именно. И раз уж ты говоришь, что фичи для тебя не на первом и не на втором месте (к тому же такие несерьёзные то в следующий раз лучше бы о более важных вещах поговорить.
Кстати, вот реальный пример, в отличии от твоих надуманных.
Чтобы тебе было таки чем гордиться.
Появление net/ipv4/fib_trie.c (ожидается в 2.6.13)
Чтобы тебе было таки чем гордиться.
Появление net/ipv4/fib_trie.c (ожидается в 2.6.13)
Появление IP стека в Линукс? Если серьёзно, то мы тоже движемся во встречном вам направлении - ARP будет оторван от роутинга и будет просто хэшом.
А на данный момент:
IP: BSD - trie, Linux - хэш
ARP: BSD - странно приклеено к trie, Linux - хэш
А на данный момент:
IP: BSD - trie, Linux - хэш
ARP: BSD - странно приклеено к trie, Linux - хэш
Кстати, это уже будет не два года, а десять. И то и другое.
> ARP: BSD - странно приклеено к trie, Linux - хэш
Оно конечно хэш, но ещё и привязывается к dst cache (по крайней мере так было, когда я смотрел).
А зачем в BSD отрывают?
Оно конечно хэш, но ещё и привязывается к dst cache (по крайней мере так было, когда я смотрел).
А зачем в BSD отрывают?
Потому что так, как сейчас, это по-уродски с точки зрения идеологии. Ведь это link layer mapping, который к IPv4 routing никакого отношения не имеет. На практике это гемор с локами и прочим.
P.S. Кстати не в BSD, а только в FreeBSD.
P.S. Кстати не в BSD, а только в FreeBSD.
Ну для достижения максимальной производительности разделение на уровни то и дело нарушают. Чего стоят хотя бы сетевые карты, считающие контрольные суммы TCP и UDP, не говоря уже о TSO и прочем.
В данном случае нарушение было не ради производительности, а просто потому, что давным давно так показалось проще, чем заводить новый уровень. Как будет с производительностью нового ARPа пока не ясно. Конечно, новый подход будет протестирован не только на работоспособность, но и на скорость перед вливанием в дерево.
Оставить комментарий
sergey_m
http://lwn.net/Articles/138174/Оба нововведения (sleep mutexes и interrupt kernel threads) были еще в FreeBSD 5.2-RELEASE, полтора года назад. Даже уже книга издана, где этот подход описывается. К моменту, когда будет первый релиз какого-нибудь Linux с этими пока только запланированными изменениями, пройдёт как раз года два.