Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
| | |
Как я понимаю вам просто на диспетч для ускорения... 06.03.04 14:47 Число просмотров: 1264
Автор: Sergio Статус: Незарегистрированный пользователь
|
> Делать вытеснение или поддержку приоритетов для fiber-ов не
> нужно "по определению". При выполнении кода в fiber все
> сводиться к тому, что вместо засыпания по WaitFor
> происходит переключение на другой стек/контекст, но все это
> преимущественно в одном thread и без использования
> kernel-dispatch.
>
> Обработка Power-Managenet IRP не допускает прямого ожидания
> (IRQL may == DISPATCH_LEVEL), только STATUS_PENDING. Но для
> functional devices при выключении необходимо как минимум
> дождаться IoDone, поэтому асинхронного выполнение IRP в
> IoWorkItem или отдельном thread не избежать.
>
> Для Bus драйвера задействование IoWorkItem в
> Power-Management может приводить к "мягкому" dead-lock
> (компьютер бесконечно долго выключает питание). Поэтому
> необходимо обслуживать IRP в персональном thread, но это
> достаточно дорого, особенно когда 100-200 child-devices.
>
> Именно поэтому я сделал fibers: Логика выполнения как-будно
> в персональном thread (или IoWorkItem), но при этом thread
> только один.
> Суть моего вопроса была в другом - что плохого может быть
> при подмене стека ядра, без обновления полей в системном
> thread-объекте. Ну конечно кроме очевидных вещей, как
> например то, что IoGetStackLimits() и IoGetInitialStack()
> теряют актуальность, или отслеживание APC_LEVEL при
> переброске fiber-ов между threads.
Как я понимаю вам просто на диспетч для ускорения выключения необходимо "паралельно ожидать" завершения некоторых действий?
Насколько я помню в структуре ктреда нет полей, жестко привязанных с текущему стеку ядра. А возможные проблемы - (возможно) использование переменных ядра, сервисов, использующих эти переменные, эксепшены....всего, что может быть жестко привязано к стеку.
это все лежит за рамками документированного M$ и проверяется только.......опытом=) Вот зачем только надо перезагружать стек, я думаю без этого можно обойтись.
|
|
<programming>
|
[NT-kernel-deep] Kernel mode Fibers, переключение стеков/контекстов 02.03.04 17:17
Автор: leo <Леонид Юрьев> Статус: Elderman
Отредактировано 02.03.04 17:24 Количество правок: 1
|
Для управления питанием bus-fdo и child-pdo в драйвере с большим количеством дочерних устройств, реализовал fiber-ы в режиме ядра (см. fibers в pladform sdk/mdsn).
Так сложно потому, что создавать thread на каждый irp - слишком расточительно, а использование work-items порождает dead-locks.
Пока работает, и даже с driver verifier-ом:). Но ради простоты я "наплевал" на user-mode-stack, кроме этого конечно умер stack-grow, и наверное еще что-нибудь. Поэтому и ВОПРОС: кто-нибудь делал что-либо подобное, или слышал? Может есть известные проблемы?
Исходники NT4 и W2K я конечно просмотрю, но много их...
|
|
Сомневаюсь, что ты эффективно сделал переключение нитей... 05.03.04 14:55
Автор: Sergio Статус: Незарегистрированный пользователь
|
> Для управления питанием bus-fdo и child-pdo в драйвере с
> большим количеством дочерних устройств, реализовал fiber-ы
> в режиме ядра (см. fibers в pladform sdk/mdsn).
> Так сложно потому, что создавать thread на каждый irp -
> слишком расточительно, а использование work-items порождает
> dead-locks.
>
> Пока работает, и даже с driver verifier-ом:). Но ради
> простоты я "наплевал" на user-mode-stack, кроме этого
> конечно умер stack-grow, и наверное еще что-нибудь. Поэтому
> и ВОПРОС: кто-нибудь делал что-либо подобное, или слышал?
> Может есть известные проблемы?
>
> Исходники NT4 и W2K я конечно просмотрю, но много их...
Сомневаюсь, что ты эффективно сделал переключение нитей. Если нити переключаются не через последовательный опрос то может кинешь поглядеть %) Подробнее про проблему можно зачем на каждый irp свой поток/нить? Сомневаюсь что нужно это было делать... У меня тоже пока работает таймаут по отсутствию (для простоты скажем) одного из шести прерываний и это работает в отдельном потоке с последовательным опросом (можно тоже сказать нити).....а реально и правильней делать в моем случае через кэнселейшн.
ЗЫ
C DV должно проходить и *NULL = NULL;
|
| |
Делать вытеснение или поддержку приоритетов для fiber-ов не... 05.03.04 16:39
Автор: leo <Леонид Юрьев> Статус: Elderman
|
> Сомневаюсь, что ты эффективно сделал переключение нитей.
> Если нити переключаются не через последовательный опрос то
> может кинешь поглядеть %) Подробнее про проблему можно
> зачем на каждый irp свой поток/нить? Сомневаюсь что нужно
> это было делать... У меня тоже пока работает таймаут по
> отсутствию (для простоты скажем) одного из шести прерываний
> и это работает в отдельном потоке с последовательным
> опросом (можно тоже сказать нити).....а реально и
> правильней делать в моем случае через кэнселейшн.
Делать вытеснение или поддержку приоритетов для fiber-ов не нужно "по определению". При выполнении кода в fiber все сводиться к тому, что вместо засыпания по WaitFor происходит переключение на другой стек/контекст, но все это преимущественно в одном thread и без использования kernel-dispatch.
Обработка Power-Managenet IRP не допускает прямого ожидания (IRQL may == DISPATCH_LEVEL), только STATUS_PENDING. Но для functional devices при выключении необходимо как минимум дождаться IoDone, поэтому асинхронного выполнение IRP в IoWorkItem или отдельном thread не избежать.
Для Bus драйвера задействование IoWorkItem в Power-Management может приводить к "мягкому" dead-lock (компьютер бесконечно долго выключает питание). Поэтому необходимо обслуживать IRP в персональном thread, но это достаточно дорого, особенно когда 100-200 child-devices.
Именно поэтому я сделал fibers: Логика выполнения как-будно в персональном thread (или IoWorkItem), но при этом thread только один.
Если вы не написали "с нуля" и не отладили хотя-бы один bus-дайвер с полной поддержкой управления питанием, то понять зачем мне понадобились fibers достаточно сложно. В M$ в таких случаях говорят однозначно – каждый SET/QUERY_POWER IRP выполнять в отдельном потоке, а я вот решил сделать «хитрее».
Cancellation тут совершенно ни при чем, в вашем случае можно уверенно обойтись и без thread (что будет дешевле для системы в целом).
Суть моего вопроса была в другом - что плохого может быть при подмене стека ядра, без обновления полей в системном thread-объекте. Ну конечно кроме очевидных вещей, как например то, что IoGetStackLimits() и IoGetInitialStack() теряют актуальность, или отслеживание APC_LEVEL при переброске fiber-ов между threads.
|
| | |
Как я понимаю вам просто на диспетч для ускорения... 06.03.04 14:47
Автор: Sergio Статус: Незарегистрированный пользователь
|
> Делать вытеснение или поддержку приоритетов для fiber-ов не
> нужно "по определению". При выполнении кода в fiber все
> сводиться к тому, что вместо засыпания по WaitFor
> происходит переключение на другой стек/контекст, но все это
> преимущественно в одном thread и без использования
> kernel-dispatch.
>
> Обработка Power-Managenet IRP не допускает прямого ожидания
> (IRQL may == DISPATCH_LEVEL), только STATUS_PENDING. Но для
> functional devices при выключении необходимо как минимум
> дождаться IoDone, поэтому асинхронного выполнение IRP в
> IoWorkItem или отдельном thread не избежать.
>
> Для Bus драйвера задействование IoWorkItem в
> Power-Management может приводить к "мягкому" dead-lock
> (компьютер бесконечно долго выключает питание). Поэтому
> необходимо обслуживать IRP в персональном thread, но это
> достаточно дорого, особенно когда 100-200 child-devices.
>
> Именно поэтому я сделал fibers: Логика выполнения как-будно
> в персональном thread (или IoWorkItem), но при этом thread
> только один.
> Суть моего вопроса была в другом - что плохого может быть
> при подмене стека ядра, без обновления полей в системном
> thread-объекте. Ну конечно кроме очевидных вещей, как
> например то, что IoGetStackLimits() и IoGetInitialStack()
> теряют актуальность, или отслеживание APC_LEVEL при
> переброске fiber-ов между threads.
Как я понимаю вам просто на диспетч для ускорения выключения необходимо "паралельно ожидать" завершения некоторых действий?
Насколько я помню в структуре ктреда нет полей, жестко привязанных с текущему стеку ядра. А возможные проблемы - (возможно) использование переменных ядра, сервисов, использующих эти переменные, эксепшены....всего, что может быть жестко привязано к стеку.
это все лежит за рамками документированного M$ и проверяется только.......опытом=) Вот зачем только надо перезагружать стек, я думаю без этого можно обойтись.
|
| | | |
Re: зачем только надо перезагружать стек, я думаю 07.03.04 14:50
Автор: leo <Леонид Юрьев> Статус: Elderman
Отредактировано 07.03.04 17:50 Количество правок: 1
|
> Вот зачем только надо
> перезагружать стек, я думаю без этого можно обойтись.
Извините, но у меня создалось впечатление, что вы либо не внимательно читаете мои сообщения, либо недостаточно компетентны чтобы говорить на эту тему.
|
| | | | |
Я никогда не писал шинных драйверов и поэтому совершенно не... 09.03.04 12:45
Автор: Sergio Статус: Незарегистрированный пользователь
|
> > Вот зачем только надо
> > перезагружать стек, я думаю без этого можно обойтись.
>
> Извините, но у меня создалось впечатление, что вы либо не
> внимательно читаете мои сообщения, либо недостаточно
> компетентны чтобы говорить на эту тему.
Я никогда не писал шинных драйверов и поэтому совершенно не представляю проблем возникающих при их написании.
Вы просто попробуйте простым языком в ДВУХ словах обьяснить что требуется. Как я понимаю Вам на уровне диспетч требуется ожидать завершение работы от нескольких устройст. Вы сделали это через реализацию нитей. Ок. Проблемы то какие? Опыт вам нужен? У меня такого нет.
|
|
|
подробно о проекте
Анализ криптографических сетевых...
