亚洲av成人无遮挡网站在线观看,少妇性bbb搡bbb爽爽爽,亚洲av日韩精品久久久久久,兔费看少妇性l交大片免费,无码少妇一区二区三区

Chinaunix

標(biāo)題: 關(guān)于LINUX在中斷（硬軟）中不能睡眠的真正原因 [打印本頁]

作者: 思一克 時(shí)間: 2007-06-27 09:19
標(biāo)題: 關(guān)于LINUX在中斷（硬軟）中不能睡眠的真正原因
看鄰居帖子，大家回答的問題不大。但也有不同的回答和解釋。有點(diǎn)亂。

有必要討論，得出固定的結(jié)論。

作者: xiegang112 時(shí)間: 2007-06-27 09:29
確實(shí)，大家說了很多，有些地方還是不是很清楚。
希望高手們能給出正解

作者: scutan 時(shí)間: 2007-06-27 09:38

原帖由 思一克 于 2007-6-27 09:19 發(fā)表于 1樓
看鄰居帖子，大家回答的問題不大。但也有不同的回答和解釋。有點(diǎn)亂。

有必要討論，得出固定的結(jié)論。

其實(shí)這只是一個(gè)設(shè)計(jì)上的問題, 而并不是強(qiáng)制的. 只是針對(duì)Linux內(nèi)核而言, 這是規(guī)矩.
LKD2上面說, 切換出去之后, 何時(shí)才能調(diào)度回來? 就是中斷回來之后可能不會(huì)回到之前所依俯的那個(gè)進(jìn)程了.
中斷不能睡眠的的最大好處就是可以簡(jiǎn)化內(nèi)核的設(shè)計(jì). 如果說中斷隨時(shí)可以睡眠的話, 那么就必須考慮很多其它方面的事情, 比如睡眠之后又出現(xiàn)了
同一IRQ號(hào)的中斷又該怎么辦, 等等.
其實(shí), 如果自己能把握好, 中斷中睡眠也是可以的. 但是必須能夠保證這段代碼具有足夠的安全性與可靠性.
這是我的理解.

作者: zx_wing 時(shí)間: 2007-06-27 10:09
呵呵，我最喜歡這種討論了。先來獻(xiàn)丑了，說說我的看法。
先把中斷處理流程給出來

1.進(jìn)入中斷處理程序--->2.保存關(guān)鍵上下文---->3.開中斷（sti指令）--->4.進(jìn)入中斷處理程序的handler--->5.關(guān)中斷（cli指令）---->6.寫EOI寄存器（表示中斷處理完成）---->7.開中斷。

復(fù)制代碼

硬中斷：
對(duì)應(yīng)于上圖的1、2、3步驟，在這幾個(gè)步驟中，所有中斷是被屏蔽的，如果在這個(gè)時(shí)候睡眠了，操作系統(tǒng)不會(huì)收到任何中斷（包括時(shí)鐘中斷），系統(tǒng)就基本處于癱瘓狀態(tài)（例如調(diào)度器依賴的時(shí)鐘節(jié)拍沒有等等……）

軟中斷：
對(duì)應(yīng)上圖的4（當(dāng)然，準(zhǔn)確的說應(yīng)該是4步驟的后面一點(diǎn)，先把話說保險(xiǎn)點(diǎn)，免得思一克又開始較真

）。這個(gè)時(shí)候不能睡眠的關(guān)鍵是因?yàn)樯舷挛摹?br /> 大家知道操作系統(tǒng)以進(jìn)程調(diào)度為單位，進(jìn)程的運(yùn)行在進(jìn)程的上下文中，以進(jìn)程描述符作為管理的數(shù)據(jù)結(jié)構(gòu)。進(jìn)程可以睡眠的原因是操作系統(tǒng)可以切換不同進(jìn)程的上下文，進(jìn)行調(diào)度操作，這些操作都以進(jìn)程描述符為支持。
中斷運(yùn)行在中斷上下文，沒有一個(gè)所謂的中斷描述符來描述它，它不是操作系統(tǒng)調(diào)度的單位。一旦在中斷上下文中睡眠，首先無法切換上下文（因?yàn)闆]有中斷描述符，當(dāng)前上下文的狀態(tài)得不到保存），其次，沒有人來喚醒它，因?yàn)樗皇遣僮飨到y(tǒng)的調(diào)度單位。
此外，中斷的發(fā)生是非常非常頻繁的，在一個(gè)中斷睡眠期間，其它中斷發(fā)生并睡眠了，那很容易就造成中斷棧溢出導(dǎo)致系統(tǒng)崩潰。

如果上述條件滿足了（也就是有中斷描述符，并成為調(diào)度器的調(diào)度單位，棧也不溢出了，理論上是可以做到中斷睡眠的），中斷是可以睡眠的，但會(huì)引起很多問題.例如，你在時(shí)鐘中斷中睡眠了，那操作系統(tǒng)的時(shí)鐘就亂了，調(diào)度器也了失去依據(jù)；例如，你在一個(gè)IPI（處理器間中斷）中，其它CPU都在死循環(huán)等你答復(fù)，你確睡眠了，那其它處理器也不工作了；例如，你在一個(gè)DMA中斷中睡眠了，上面的進(jìn)程還在同步的等待I/O的完成，性能就大大降低了……還可以舉出很多例子。所以，中斷是一種緊急事務(wù)，需要操作系統(tǒng)立即處理，不是不能做到睡眠，是它沒有理由睡眠。

好了，羅嗦了一大堆，大家見仁見智，不要罵人就好。

作者: 思一克 時(shí)間: 2007-06-27 10:20
zx_wing, scutan 謝謝

作者: 思一克 時(shí)間: 2007-06-27 10:21
那么LINUX有在中斷中睡眠的地方嗎

作者: zx_wing 時(shí)間: 2007-06-27 10:31

原帖由 思一克 于 2007-6-27 10:21 發(fā)表于 6樓
那么LINUX有在中斷中睡眠的地方嗎

據(jù)我所知沒有。但有沒有人在他自己寫的驅(qū)動(dòng)程序的中斷處理handler中睡眠就不知道了

作者: gta 時(shí)間: 2007-06-27 13:29
任何os，不管是分時(shí)os，還是實(shí)時(shí)os，不管是微內(nèi)核，還是巨內(nèi)核，在ISR中都不能進(jìn)行進(jìn)程切換。因?yàn)镮SR不屬于任何進(jìn)程，而切換只能發(fā)生在進(jìn)程上下文中。雖然ISR在執(zhí)行過程中要使用進(jìn)程的系統(tǒng)堆棧，但那只是借用，堆棧并不屬于isr，而是屬于進(jìn)程。
也可以從優(yōu)先級(jí)角度來理解。任何進(jìn)程，不論其優(yōu)先級(jí)多高，也不能高過isr，所以不能剝奪isr對(duì)cpu的占有權(quán)去運(yùn)行進(jìn)程

作者: Solaris12 時(shí)間: 2007-06-27 13:58

原帖由 gta 于 2007-6-27 13:29 發(fā)表于 8樓
任何os，不管是分時(shí)os，還是實(shí)時(shí)os，不管是微內(nèi)核，還是巨內(nèi)核，在ISR中都不能進(jìn)行進(jìn)程切換。因?yàn)镮SR不屬于任何進(jìn)程，而切換只能發(fā)生在進(jìn)程上下文中。雖然ISR在執(zhí)行過程中要使用進(jìn)程的系統(tǒng)堆棧，但那只是借用， ...

呵呵，Solaris的低優(yōu)先級(jí)中斷是可以睡眠的，時(shí)鐘中斷也可以睡眠。盡管系統(tǒng)會(huì)盡量保證中斷線程不去睡眠。例如，磁盤驅(qū)動(dòng)的ISR里使用DRIVEDR mutex, 實(shí)際上系統(tǒng)把它當(dāng)作自適應(yīng)鎖，當(dāng)獲取鎖失敗時(shí)，它先看其它處理器上有沒有鎖的擁有者在運(yùn)行，如果有，就SPIN,沒有就去睡眠，睡眠前，會(huì)把打斷的內(nèi)核線程恢復(fù)運(yùn)行，保存自己的上下文。

作者: Solaris12 時(shí)間: 2007-06-27 14:04

原帖由 zx_wing 于 2007-6-27 10:09 發(fā)表于 4樓
呵呵，我最喜歡這種討論了。先來獻(xiàn)丑了，說說我的看法。
先把中斷處理流程給出來

1.進(jìn)入中斷處理程序--->2.保存關(guān)鍵上下文---->3.開中斷（sti指令）--->4.進(jìn)入中斷處理程序的handler--->5.關(guān)中 ...

寫得很好。贊一個(gè)。

不過中斷睡眠與否只是設(shè)計(jì)上的問題，不同的系統(tǒng)是不一樣的設(shè)計(jì)。

看看我自己機(jī)器上注冊(cè)的ISR, IPL是10以下的都可以睡眠，里面包括了顯卡，磁盤，網(wǎng)卡的常見外設(shè)的中斷處理：

bash-3.00# mdb -k
Loading modules: [ unix genunix specfs dtrace uppc pcplusmp scsi_vhci ufs ip hook neti sctp arp usba uhci nca lofs zfs random audiosup sppp crypto ptm ipc ]
> ::interrupts
IRQ  Vect IPL Bus Trg Type CPU Share APIC/INT# ISR(s)
1 0x41 5 ISA Edg Fixed  0 1    0x0/0x1 i8042_intr
6 0x44 5 ISA Edg Fixed  0 1    0x0/0x6 fdc_intr
9 0x81 9 PCI Lvl Fixed  0 1    0x0/0x9 acpi_wrapper_isr
12 0x42 5 ISA Edg Fixed  0 1    0x0/0xc i8042_intr
14 0x40 5 ISA Edg Fixed  0 1    0x0/0xe ata_intr
15 0x43 5 ISA Edg Fixed  0 1    0x0/0xf ata_intr
16 0x82 9 PCI Lvl Fixed  0 1    0x0/0x10  nv_intr
21 0x20 1 PCI Lvl Fixed  0 4    0x0/0x15  uhci_intr, uhci_intr, uhci_intr, ehci_intr
22 0x83 9 PCI Lvl Fixed  0 1    0x0/0x16  audiovia823x_intr
23 0x60 6 PCI Lvl Fixed  0 1    0x0/0x17  gem_gld_intr
208  0xd0 14       Edg IPI all 1    -       kcpc_hw_overflow_intr
209  0xd1 14       Edg IPI all 1    -       cbe_fire
224  0xe0 15       Edg IPI all 1    -       apic_error_intr

作者: bluster 時(shí)間: 2007-06-27 14:27

原帖由 zx_wing 于 2007-6-27 10:09 發(fā)表于 4樓
呵呵，我最喜歡這種討論了。先來獻(xiàn)丑了，說說我的看法。
先把中斷處理流程給出來

1.進(jìn)入中斷處理程序--->2.保存關(guān)鍵上下文---->3.開中斷（sti指令）--->4.進(jìn)入中斷處理程序的handler--->5.關(guān)中 ...

我覺得主要是調(diào)度的問題，引入中斷線程問題就基本解決了。

作者: 思一克 時(shí)間: 2007-06-27 16:43
LINUX上中斷中不能睡眠（調(diào)用schedule,直接或間接）和“被中斷的進(jìn)程和中斷本身無關(guān)系”無關(guān)。

前面有人說“被中斷的進(jìn)程和中斷本身無關(guān)系”是不能睡眠的原因。我不理解，覺得說法不對(duì)。

作者: motalelf 時(shí)間: 2007-06-27 17:15

原帖由 思一克 于 2007-6-27 16:43 發(fā)表于 12樓
LINUX上中斷中不能睡眠（調(diào)用schedule,直接或間接）和“被中斷的進(jìn)程和中斷本身無關(guān)系”無關(guān)。

前面有人說“被中斷的進(jìn)程和中斷本身無關(guān)系”是不能睡眠的原因。我不理解，覺得說法不對(duì)。

這沒什么不對(duì)，中斷和自陷在執(zhí)行的路徑上，沒有絲毫不同。如果說什么“中斷是因?yàn)闆]有進(jìn)程上下文，只有中斷上下文”而不能睡眠的話；那么自陷同樣“沒有進(jìn)程上下文，只有自陷上下文”。

但是自陷卻可以睡眠，最明顯的就是缺頁異常，睡眠再正常不過了。就是因?yàn)楫?dāng)前發(fā)生的異常和當(dāng)前進(jìn)程有關(guān)系，把當(dāng)前進(jìn)程睡眠掉并不冤枉它。

作者: gta 時(shí)間: 2007-06-27 17:52

原帖由 Solaris12 于 2007-6-27 13:58 發(fā)表于 9樓

呵呵，Solaris的低優(yōu)先級(jí)中斷是可以睡眠的，時(shí)鐘中斷也可以睡眠。盡管系統(tǒng)會(huì)盡量保證中斷線程不去睡眠。例如，磁盤驅(qū)動(dòng)的ISR里使用DRIVEDR mutex, 實(shí)際上系統(tǒng)把它當(dāng)作自適應(yīng)鎖，當(dāng)獲取鎖失敗時(shí)，它先看其 ...

ISR(interrupt service routine)是不能睡眠的，我覺得你說的那個(gè)不是ISR，是IST(interrupt service thread).IST平時(shí)處于睡眠態(tài)，發(fā)生中斷后，cpu執(zhí)行ISR,在ISR中喚醒IST,中斷服務(wù)的主體在IST中完成。引入IST后，一來可以減小內(nèi)核體積，二來可以減小不可剝奪窗口，增強(qiáng)調(diào)度的實(shí)時(shí)性。WIN CE就是這樣做的。不知Solaris的做法是否與此類似。請(qǐng)Solaris12兄指教

[ 本帖最后由 gta 于 2007-6-27 17:54 編輯 ]

作者: motalelf 時(shí)間: 2007-06-27 19:35

原帖由 gta 于 2007-6-27 17:52 發(fā)表于 14樓
呵呵，Solaris的低優(yōu)先級(jí)中斷是可以睡眠的，時(shí)鐘中斷也可以睡眠。盡管系統(tǒng)會(huì)盡量保證中斷線程不去睡眠。例如，磁盤驅(qū)動(dòng)的ISR里使用DRIVEDR mutex, 實(shí)際上系統(tǒng)把它當(dāng)作自適應(yīng)鎖，當(dāng)獲取鎖失敗時(shí)，它先看其 ...

退一萬步說，假如中斷可以睡眠，那么也決不是低優(yōu)先級(jí)中斷可以睡眠；而是當(dāng)前進(jìn)程為低優(yōu)先級(jí)進(jìn)程時(shí)能睡眠。不然那些進(jìn)程調(diào)度算法不白寫了？高優(yōu)先級(jí)的進(jìn)程有什么用？只要碰到個(gè)低優(yōu)先級(jí)中斷就被調(diào)度出去了。

雖然我不知道Solaris長(zhǎng)的什么摸樣。

作者: 思一克 時(shí)間: 2007-06-27 20:24
自陷就是TRAP，LINUX的EXCEPTION－異常，有進(jìn)程上下文。

TRAP，相當(dāng)于一個(gè)軟中斷（INT 1， INT 3，斷點(diǎn)，單步等），和軟中斷調(diào)用的系統(tǒng)調(diào)用（INT 21， INT 80)幾乎一樣，屬于當(dāng)前進(jìn)程，進(jìn)入內(nèi)核使用進(jìn)程的內(nèi)核棧。唯一不同的是，系統(tǒng)調(diào)用的軟中斷在用戶程序中的位置相對(duì)固定，而TRAP相對(duì)不固定。

假定INT 0是被0除TRAP，你在USER中執(zhí)行A ＝ 1／0和執(zhí)行INT 0是一樣的，而INT 0 和INT 80也是一樣的。用戶程序執(zhí)行INT 80有進(jìn)程CONTEXT, 執(zhí)行INT 0也一樣有進(jìn)程CONTEXT.

可以看出，TRAP(比如INT 0)的PROCESS CONTEXT和執(zhí)行系統(tǒng)調(diào)用INT 80后的PROCESS CONTEXT是一樣的。所以TRAP中如果睡眠了，是可以回來的。

而中斷沒有進(jìn)程上下文。調(diào)度后無法回來.

如果不想回來了, 中斷中也是可以睡眠的.

正因?yàn)門RAP和中斷有如此不同，LINUX系統(tǒng)中才對(duì)于INTERRUPT 和 EXCEPTION的處理才是非常不同。

我理解的前面的說的中斷和進(jìn)程無關(guān)大概就是這個(gè)意思（？）

原帖由 motalelf 于 2007-6-27 17:15 發(fā)表于 13樓

這沒什么不對(duì)，中斷和自陷在執(zhí)行的路徑上，沒有絲毫不同。如果說什么“中斷是因?yàn)闆]有進(jìn)程上下文，只有中斷上下文”而不能睡眠的話；那么自陷同樣“沒有進(jìn)程上下文，只有自陷上下文”。

但是自陷卻可以 ...

作者: Solaris12 時(shí)間: 2007-06-27 20:25

原帖由 gta 于 2007-6-27 17:52 發(fā)表于 14樓
ISR(interrupt service routine)是不能睡眠的，我覺得你說的那個(gè)不是ISR，是IST(interrupt service thread).IST平時(shí)處于睡眠態(tài)，發(fā)生中斷后，cpu執(zhí)行ISR,在ISR中喚醒IST,中斷服務(wù)的主體在IST中完成。引入IST后，一來可以減小內(nèi)核體積，二來可以減小不可剝奪窗口，增強(qiáng)調(diào)度的實(shí)時(shí)性。WIN CE就是這樣做的。不知Solaris的做法是否與此類似。請(qǐng)Solaris12兄指教

Cool!

你說的很準(zhǔn)確。的確是你說的情況。

舉例來說，寫網(wǎng)卡驅(qū)動(dòng)程序，我們通常把中斷服務(wù)函數(shù)說成ISR。

但在Solaris里，每個(gè)級(jí)低優(yōu)先級(jí)中斷都有個(gè)IST,中斷服務(wù)線程。

我說的ISR是驅(qū)動(dòng)程序的中斷服務(wù)函數(shù)，即下面的e1000g`e1000g_intr，而你說的是下面調(diào)用棧里的_interrupt。

具體機(jī)制和你說的一樣，下面的調(diào)用棧是我觀察網(wǎng)卡驅(qū)動(dòng)e1000g調(diào)用棧得到的：

[6]> ffffff001ddabc80::threadlist -v
         ADDR          PROC             LWP CLS PRI          WCHAN
ffffff001ddabc80 fffffffffbc24b30 fffffffec8551170 0 165             0
  PC: thread_start THREAD: thread_create_intr()
  stack pointer for thread ffffff001ddabc80: ffffff001ddabbc0
e1000g`e1000g_intr+8(2)
av_dispatch_autovect+0x78()
dispatch_hardint+0x2f()
switch_sp_and_call+0x13()
do_interrupt+0xa0()
_interrupt+0xba()

作者: Solaris12 時(shí)間: 2007-06-27 20:30

原帖由 motalelf 于 2007-6-27 19:35 發(fā)表于 15樓
退一萬步說，假如中斷可以睡眠，那么也決不是低優(yōu)先級(jí)中斷可以睡眠；而是當(dāng)前進(jìn)程為低優(yōu)先級(jí)進(jìn)程時(shí)能睡眠。不然那些進(jìn)程調(diào)度算法不白寫了？高優(yōu)先級(jí)的進(jìn)程有什么用？只要碰到個(gè)低優(yōu)先級(jí)中斷就被調(diào)度出去了。

雖然我不知道Solaris長(zhǎng)的什么摸樣。

Solaris的中斷服務(wù)線程有獨(dú)立的調(diào)度優(yōu)先級(jí)，一般是160-169。其中時(shí)鐘中斷最高，是169。

在Solaris里時(shí)鐘中斷是最高的調(diào)度優(yōu)先級(jí)。

當(dāng)然，高優(yōu)先級(jí)中斷一來，就立即執(zhí)行，根本不涉及到調(diào)度問題。

我曾經(jīng)給Solaris調(diào)度器提交過一個(gè)bug，其中就涉及到時(shí)鐘中斷睡眠的情形

[ 本帖最后由 Solaris12 于 2007-6-27 22:53 編輯 ]

作者: xiaozhaoz 時(shí)間: 2007-06-27 22:00
標(biāo)題: 中斷sleep, preempt和實(shí)時(shí)性瓶頸介紹.

原帖由 zx_wing 于 2007-6-27 10:09 發(fā)表于 4樓
呵呵，我最喜歡這種討論了。先來獻(xiàn)丑了，說說我的看法。
先把中斷處理流程給出來

1.進(jìn)入中斷處理程序--->2.保存關(guān)鍵上下文---->3.開中斷（sti指令）--->4.進(jìn)入中斷處理程序的handler--->5.關(guān)中 ...

里面很多說法不是很同意, 個(gè)人認(rèn)為中斷處理handler不能sleep原因應(yīng)該不是上面那些.

我們都是從理論講下面這些問題, 因?yàn)閘inux在很多地方做了保護(hù), 所以直接sleep或者schedule()會(huì)導(dǎo)致內(nèi)核異常.

首先分清楚, 我們討論的是不能sleep, 而不是不能preempt.

1. 毫無疑問, 在關(guān)中斷的時(shí)候不能sleep, 這點(diǎn)大家都知道, 因?yàn)闀r(shí)鐘中斷無法觸發(fā). 但不是所有情況下, 在關(guān)中斷時(shí)sleep都會(huì)導(dǎo)致系統(tǒng)死掉, 在SMP的情況下, 可能系統(tǒng)不會(huì)死掉.

2.  中斷的handler能否sleep?
   這其實(shí)和"中斷沒有自己的上下文"無關(guān). CPU沒有關(guān)中斷, 中斷有自己的上下文, 中斷的上下文就是搶占的任務(wù)A的上下文.
   和棧溢出也沒有關(guān)系, 現(xiàn)在的中斷都是可以嵌套的, 如果中斷sleep只會(huì)讓后面的中斷搶占其他任務(wù), 根本不存在棧溢出問題, 不過現(xiàn)在內(nèi)核的4K中斷單獨(dú)棧會(huì)有問題. 這會(huì)導(dǎo)致棧被破壞.

假設(shè)中斷sleep了, 在調(diào)度的時(shí)候, 內(nèi)核將中斷的CS:eip和SS:esp保存在被搶占任務(wù)A的thread_info中, 當(dāng)任務(wù)A被重新喚醒的時(shí)候, 任務(wù)A從中斷的CS:eip開始執(zhí)行, 這也能正常執(zhí)行下去, 中斷執(zhí)行完后, 從ret_from_intr中返回. 可以恢復(fù)任務(wù)A的搶占前的場(chǎng)景.

Linux內(nèi)核要實(shí)現(xiàn)成這樣, 必須解決下面問題:
中斷sleep會(huì)增加普通任務(wù)的不確定性, 普通任務(wù)執(zhí)行的時(shí)間, 實(shí)時(shí)性都得不到保障.
和中斷共享中斷號(hào)的中斷會(huì)受到影響, 現(xiàn)在的內(nèi)核設(shè)置了INPROGRESS標(biāo)志.
中斷因?yàn)榻栌昧吮粨屨既蝿?wù)的上下文, 所以中斷的處理受到任務(wù)上下文屬性的限制.
等等很多其他問題, 總之, 中斷sleep會(huì)導(dǎo)致被搶占任務(wù)的不確定性, 并可能導(dǎo)致其他中斷受影響.

總結(jié):
異步異常(中斷)handler不是沒有上下文, 而是沒有固定的上下文,  如果使用被搶占的任務(wù)作為上下文, 一,自身的處理無法得到實(shí)時(shí)保障,導(dǎo)致系統(tǒng)不確定性, 二,任務(wù)受到影響.

如何解決:
給中斷handler提供固定的內(nèi)核線程上下文!!
這樣, 中斷不能sleep, 但中斷的handler可以sleep!
為每個(gè)中斷號(hào)創(chuàng)建一個(gè)內(nèi)核任務(wù), 中斷入口函數(shù)do_irq只是喚醒相應(yīng)的中斷任務(wù), 中斷任務(wù)去執(zhí)行相應(yīng)的handler.

好處:
   提高了系統(tǒng)的實(shí)時(shí)性. 后面可以詳細(xì)講.
壞處:
   降低了中斷, 軟中斷的實(shí)時(shí)性, 所以不是所有的中斷handler都可以在固定內(nèi)核任務(wù)上下文中處理. 一般來說, 時(shí)鐘中斷必須保證其實(shí)時(shí)性, 所以留在中斷上下文中.

介紹: Linux系統(tǒng)的實(shí)時(shí)性瓶頸在哪里??
一個(gè)實(shí)時(shí)性系統(tǒng), 必須保證: 系統(tǒng)中優(yōu)先級(jí)高的任務(wù), 被喚醒后, 在很小的可控的延時(shí)內(nèi), CS:eip指令得到執(zhí)行.
一個(gè)好的實(shí)時(shí)性系統(tǒng), 必須保證: 系統(tǒng)中的所有等待運(yùn)行的任務(wù), 可以在一個(gè)固定的可接受的延時(shí)內(nèi), CS:eip指令得到執(zhí)行.
這些延時(shí)包括中斷響應(yīng)延時(shí), 中斷處理延時(shí), 調(diào)度響應(yīng)和調(diào)度處理延時(shí).

復(fù)制代碼

試想現(xiàn)有的系統(tǒng), 一個(gè)任務(wù)可能在以下上下文中被喚醒:
1. 中斷上下文, 如dma數(shù)據(jù)傳輸完成等等設(shè)備驅(qū)動(dòng).

中斷上下文喚醒任務(wù)后, 任務(wù)被加入到running隊(duì)列, 返回, 繼續(xù)執(zhí)行中斷, 中斷執(zhí)行完成后, 執(zhí)行軟中斷, 中間可能會(huì)出現(xiàn)中斷嵌套. 直到最后ret_from_intr, 才會(huì)判斷是否需要搶占當(dāng)前任務(wù). 然后調(diào)用schedule(). 從隊(duì)列被加入running隊(duì)列到schedule()函數(shù)真正開始執(zhí)行, 這段時(shí)間是中斷處理延時(shí)+調(diào)度響應(yīng)延時(shí).

如何縮短這部分延時(shí)和我們前面討論的東西很有關(guān).
正是因?yàn)橹袛?軟中斷不能preempt, 不能sleep, 導(dǎo)致了系統(tǒng)的實(shí)時(shí)性變差. 而在這些時(shí)間中, 中斷handler和軟中斷handler消耗絕大部分時(shí)間.
設(shè)想一下, 如果中斷handler和軟中斷handler放在專門的內(nèi)核任務(wù)中執(zhí)行, 中斷handler中喚醒任務(wù)A, wakeup中通過優(yōu)先級(jí)判斷handler任務(wù)是否需要被任務(wù)A搶占, 如果需要, 設(shè)置handler任務(wù)的NEED_RESCHEDULE標(biāo)志, 調(diào)用resched_task()可以馬上進(jìn)入schedule(), 其中的延時(shí)非常小, 而且非常穩(wěn)定. 當(dāng)然, 可能wakeup后, 立即有中斷到來, 但因?yàn)橹袛鄨?zhí)行路徑變得非常短, 只是喚醒響應(yīng)的handler任務(wù), 可能只需要100行以內(nèi)的代碼.所以這些時(shí)間可以忽略不計(jì). 這種做法可以極大提高系統(tǒng)的實(shí)時(shí)性.

2. 軟中斷上下文: 如定時(shí)器到期, 目的地是本地的報(bào)文送到socket層. 等等
軟中斷的情況和中斷類似, 可以通過將軟中斷線程化, 提高系統(tǒng)實(shí)時(shí)性.

3. 普通任務(wù)上下文, 如任務(wù)間通信等等.
普通任務(wù)一旦在內(nèi)核中執(zhí)行了spin_lock(), 其他任務(wù)無法搶占這個(gè)CPU, 即使另外優(yōu)先級(jí)高的任務(wù)不和它共享資源, 也無法及時(shí)得到調(diào)度. 當(dāng)CPU變多, 內(nèi)核代碼變大的時(shí)候, 這個(gè)問題也變得非常突出, 所以spin_lock()也是一個(gè)影響系統(tǒng)實(shí)時(shí)性的設(shè)計(jì). 如果將spin_lock變成可以搶占的鎖, 會(huì)是怎樣? 如果spin_lock可以搶占, 一旦任務(wù)B搶占了任務(wù)A, 而任務(wù)A執(zhí)行了spin_lock(xxx), 恰好任務(wù)B也執(zhí)行spin_lock(xxx), 必然導(dǎo)致內(nèi)核死鎖. 如果spin_lock()可以搶占, 且可以sleep(), 結(jié)果又會(huì)怎樣. 任務(wù)B執(zhí)行spin_lock(xxx)必然導(dǎo)致自己sleep, 這時(shí)任務(wù)A可以接著執(zhí)行spin_unlock(xxx),喚醒任務(wù)B. 這時(shí)又有一個(gè)優(yōu)先級(jí)反轉(zhuǎn)問題需要解決, 假設(shè)任務(wù)B的優(yōu)先級(jí)最高, 任務(wù)A最低, 任務(wù)C中等, B因?yàn)槟貌坏絰xx鎖而sleep, 重新調(diào)度, 結(jié)果調(diào)度到任務(wù)C執(zhí)行, 任務(wù)B因此喪失了優(yōu)先級(jí)優(yōu)勢(shì), 這種情況在嵌入式系統(tǒng)中可能會(huì)導(dǎo)致很嚴(yán)重的問題. 所以任務(wù)A必須繼承任務(wù)B的優(yōu)先級(jí), 重新調(diào)度的時(shí)候才能調(diào)度到任務(wù)A先運(yùn)行.

--------------------------------------------------------------------------------------
上面這些系統(tǒng)問題的改正可以提高系統(tǒng)的實(shí)時(shí)性, 但整個(gè)內(nèi)核的編程模型會(huì)變得更復(fù)雜. 這些東西就是Ingo Molnar在2005年實(shí)現(xiàn)的Realtime Patch中的核心思想, 但在2006年的Kernel Summit中, 引發(fā)了下面的討論:

http://lwn.net/Articles/191782/

注意下面這段話.
The question was asked: why bother with sleeping locks? Making locks preemptible is seen by some as a way of papering over the real problem: long lock hold times. Why not simply fix those? The answer comes in a couple of parts:

* Extensive efforts have been expended toward fixing lock problems for many years, and those efforts will continue into the future. The use of sleeping locks is not being used as an excuse to avoid fixing code which holds locks for too long.

* Ensuring realtime response in the absence of preemptible locks requires auditing the entire body of kernel source - all eight million lines or so. That's a big job, and one which is hard to keep up with in an environment where nearly ten thousand lines of code are being changed every day. Sleeping locks reduce the audit requirements to a couple thousand lines - a much more tractable problem. For those who need realtime response, guaranteed, that is a good deal.

因?yàn)楸姸嗟臓?zhēng)議, 中斷和軟中斷的線程化和spin_lock的可sleep化沒有合入主流內(nèi)核中.

如果realtime patch合并到主流內(nèi)核中, 可以滿足: 系統(tǒng)中優(yōu)先級(jí)高的任務(wù), 被喚醒后, 在很小的可控的延時(shí)內(nèi), CS:eip指令得到執(zhí)行.

但不能保證低優(yōu)先級(jí)的時(shí)延, 這正是CFS要解決的問題, 設(shè)想一下, 要讓系統(tǒng)中的任何優(yōu)先級(jí)的任務(wù)在一定的時(shí)間內(nèi)得到執(zhí)行, 必然要求等待時(shí)間長(zhǎng)的任務(wù)優(yōu)先得到執(zhí)行, CFS就是用等待時(shí)間來作為調(diào)度的依據(jù), 而優(yōu)先級(jí)居次. 有時(shí)間在討論CFS的實(shí)現(xiàn).

[ 本帖最后由 xiaozhaoz 于 2007-6-28 00:41 編輯 ]

作者: rwen2012 時(shí)間: 2007-06-27 22:04
http://hi.baidu.com/rwen2012/blo ... 28f1b4c9eaf4d0.html

作者: xiaozhaoz 時(shí)間: 2007-06-27 22:36

原帖由 rwen2012 于 2007-6-27 22:04 發(fā)表于 20樓
http://hi.baidu.com/rwen2012/blo ... 28f1b4c9eaf4d0.html

簡(jiǎn)單看了一下前面的回復(fù), 不能認(rèn)同.

問題的焦點(diǎn)大家都集中在異步異常(中斷)沒有自己的上下文?

中斷搶占了當(dāng)前任務(wù)后, 可以通過current獲得當(dāng)前的task結(jié)構(gòu), 將當(dāng)前任務(wù)的寄存器信息壓入棧中, 替換成自己的eip和esp. 你完全可以理解為當(dāng)前任務(wù)調(diào)用了handler()函數(shù). 當(dāng)然, 如果中斷使用了自己的棧, 就會(huì)有問題!!

如果handler()函數(shù)調(diào)用了
schedule_timeout_interruptible(1000)
這樣當(dāng)前任務(wù)就被加入到定時(shí)器中, 定時(shí)器軟中斷到了1000ms就會(huì)把handler搶占的任務(wù)喚醒.

當(dāng)然上述代碼要正常工作, 要修改內(nèi)核一些地方, 如schedule()里面的很多檢查, 中斷中的很多標(biāo)志位和鎖, entry.s中的很多判斷.

只是想說明, 中斷不能sleep, 不是因?yàn)闆]有上下文!

作者: Solaris12 時(shí)間: 2007-06-27 23:05

原帖由 xiaozhaoz 于 2007-6-27 22:36 發(fā)表于 21樓

簡(jiǎn)單看了一下前面的回復(fù), 不能認(rèn)同.

問題的焦點(diǎn)大家都集中在異步異常(中斷)沒有自己的上下文?

中斷搶占了當(dāng)前任務(wù)后, 可以通過current獲得當(dāng)前的task結(jié)構(gòu), 將當(dāng)前任務(wù)的寄存器信息壓入棧中, 替換成自己的eip和esp. 你完全可以理解為當(dāng)前任務(wù)調(diào)用了handler()函數(shù). 當(dāng)然, 如果中斷使用了自己的棧, 就會(huì)有問題!!

如果handler()函數(shù)調(diào)用了
schedule_timeout_interruptible(1000)
這樣當(dāng)前任務(wù)就被加入到定時(shí)器中, 定時(shí)器軟中斷到了1000ms就會(huì)把handler搶占的任務(wù)喚醒.

當(dāng)然上述代碼要正常工作, 要修改內(nèi)核一些地方, 如schedule()里面的很多檢查, 中斷中的很多標(biāo)志位和鎖, entry.s中的很多判斷.

只是想說明, 中斷不能sleep, 不是因?yàn)闆]有上下文!

的確不光是上下文的問題，比如說還有調(diào)度的問題。

假設(shè)按你說的方式中斷睡眠后，被打斷線程也跟著睡眠顯然會(huì)導(dǎo)致很多不可預(yù)知的問題。

中斷產(chǎn)生是隨機(jī)的，假設(shè)某次中斷一個(gè)內(nèi)核線程，而且按照你說的方案，這個(gè)線程的task結(jié)構(gòu)就會(huì)被借用，線程就會(huì)去睡眠。被打斷線程的優(yōu)先級(jí)如果太低，那么它很難有機(jī)會(huì)再執(zhí)行，某些情況下可能造成系統(tǒng)hang。如果臨時(shí)提高被打斷線程的優(yōu)先級(jí)，那么又需要設(shè)計(jì)新的喚醒機(jī)制來保證阻塞同一鎖上的高優(yōu)先級(jí)的線程被先喚醒。同時(shí)，要實(shí)現(xiàn)臨時(shí)提高被打斷線程的優(yōu)先級(jí)，又需要再鎖的獲取流程增加改變優(yōu)先級(jí)的算法。

總之，沒有考慮的問題還很多。

作者: xiaozhaoz 時(shí)間: 2007-06-27 23:13

原帖由 Solaris12 于 2007-6-27 23:05 發(fā)表于 22樓

的確不光是上下文的問題，比如說還有調(diào)度的問題。

假設(shè)按你說的方式中斷睡眠后，被打斷線程也跟著睡眠顯然會(huì)導(dǎo)致很多不可預(yù)知的問題。

中斷產(chǎn)生是隨機(jī)的，假設(shè)某次中斷一個(gè)內(nèi)核線程，而且按照你說的 ...

所見略同.

19樓描述的就是這個(gè)問題.

而realtime Patch解決的也是這個(gè)問題.

PS. 最近在做一個(gè)多內(nèi)核的項(xiàng)目, 包括solaris, 請(qǐng)問你們討論solaris內(nèi)核一般在哪里? OpenSolaris的mail list感覺不太熱鬧.

作者: augustusqing 時(shí)間: 2007-06-28 00:12

1. 毫無疑問, 在關(guān)中斷的時(shí)候不能sleep, 這點(diǎn)大家都知道, 因?yàn)闀r(shí)鐘中斷無法觸發(fā). 但不是所有情況下, 在關(guān)中斷時(shí)sleep都會(huì)導(dǎo)致系統(tǒng)死掉, 在SMP的情況下, 可能系統(tǒng)不會(huì)死掉.

2.  中斷的handler能否sleep?
   這其實(shí)和"中斷沒有自己的上下文"無關(guān). CPU沒有關(guān)中斷, 中斷有自己的上下文, 中斷的上下文就是搶占的任務(wù)A的上下文.
   和棧溢出也沒有關(guān)系, 現(xiàn)在的中斷都是可以嵌套的, 如果中斷sleep只會(huì)讓后面的中斷搶占其他任務(wù), 根本不存在棧溢出問題, 不過現(xiàn)在內(nèi)核的4K中斷單獨(dú)棧會(huì)有問題. 這會(huì)導(dǎo)致棧被破壞.

假設(shè)中斷sleep了, 在調(diào)度的時(shí)候, 內(nèi)核將中斷的CS:eip和SS:esp保存在被搶占任務(wù)A的thread_info中, 當(dāng)任務(wù)A被重新喚醒的時(shí)候, 任務(wù)A從中斷的CS:eip開始執(zhí)行, 這也能正常執(zhí)行下去, 中斷執(zhí)行完后, 從ret_from_intr中返回. 可以恢復(fù)任務(wù)A的搶占前的場(chǎng)景.

看著腦子里嗡嗡作響啊，共鳴啊

作者: 思一克 時(shí)間: 2007-06-28 08:39
LINUX 2。6 內(nèi)核中斷（軟中斷）自己使用自己的堆棧。
LINUX調(diào)度的單位是進(jìn)程，中斷中睡眠后因沒有CONTEXT回不來。

還有2樓說的我同意，在中斷中不讓調(diào)度主要是設(shè)計(jì)問題。所以就LINUX具體看。

如果一定要改動(dòng)系統(tǒng)，設(shè)計(jì)的中斷可以調(diào)度，是可以辦到的。

作者: Solaris12 時(shí)間: 2007-06-28 09:10

原帖由 xiaozhaoz 于 2007-6-27 23:13 發(fā)表于 23樓

所見略同.

19樓描述的就是這個(gè)問題.

而realtime Patch解決的也是這個(gè)問題.

PS. 最近在做一個(gè)多內(nèi)核的項(xiàng)目, 包括solaris, 請(qǐng)問你們討論solaris內(nèi)核一般在哪里? OpenSolaris的mail list感覺不太熱鬧.

我常去以下兩個(gè)alias，偶爾也會(huì)發(fā)言，雖然英語不大好

這兩個(gè)列表的流量相對(duì)比較大，上次休假幾天，就有上千封郵件。
你敢興趣可以發(fā)郵件訂閱，或者用下面的web界面訪問：

Code

http://www.opensolaris.org/jive/forum.jspa?forumID=12

networking

http://www.opensolaris.org/jive/forum.jspa?forumID=3

作者: zx_wing 時(shí)間: 2007-06-28 10:37

原帖由 xiaozhaoz 于 2007-6-27 22:00 發(fā)表于 19樓

里面很多說法不是很同意, 個(gè)人認(rèn)為中斷處理handler不能sleep原因應(yīng)該不是上面那些.

我們都是從理論講下面這些問題, 因?yàn)閘inux在很多地方做了保護(hù), 所以直接sleep或者schedule()會(huì)導(dǎo)致內(nèi)核異常.

首先分 ...

>>這其實(shí)和"中斷沒有自己的上下文"無關(guān). CPU沒有關(guān)中斷, 中斷有自己的上下文, 中斷的上下文就是搶占的任務(wù)A的上下文.

“中斷沒有自己的上下文”，呵呵，我沒有說這句話哈。lz很多立論在這句話上，估計(jì)是看貼的時(shí)候看錯(cuò)了。

>>假設(shè)中斷sleep了, 在調(diào)度的時(shí)候, 內(nèi)核將中斷的CS:eip和SS:esp保存在被搶占任務(wù)A的thread_info中, 當(dāng)任務(wù)A被重新喚醒的時(shí)候, 任務(wù)A從中斷的CS:eip開始執(zhí)行, 這也能正常執(zhí)行下去, 中斷執(zhí)行完后, 從ret_from_intr中返回. 可以恢復(fù)任務(wù)A的搶占前的場(chǎng)景.

這里在中斷sleep了，由誰來喚醒呢？關(guān)鍵還是沒有一個(gè)中斷描述符來作為內(nèi)核調(diào)度的單位。
前面也說到了，這是個(gè)設(shè)計(jì)問題，不是能不能實(shí)現(xiàn)的問題。
如果說把中斷的handler作為一組內(nèi)核線程，當(dāng)然是可以讓中斷睡眠的。但我始終任為中斷是緊急事務(wù)，必須立即處理，我想不出有任何理由推遲中斷的處理。

作者: zx_wing 時(shí)間: 2007-06-28 10:42

原帖由 Solaris12 于 2007-6-27 20:25 發(fā)表于 17樓

Cool!

你說的很準(zhǔn)確。的確是你說的情況。

舉例來說，寫網(wǎng)卡驅(qū)動(dòng)程序，我們通常把中斷服務(wù)函數(shù)說成ISR。

但在Solaris里，每個(gè)級(jí)低優(yōu)先級(jí)中斷都有個(gè)IST,中斷服務(wù)線程。

我說的ISR是驅(qū)動(dòng)程序的 ...

看來Solaris中的IST有點(diǎn)類似用內(nèi)核線程來實(shí)現(xiàn)中斷的handler，這種情況下應(yīng)該是可以睡眠的。
Solaris的實(shí)現(xiàn)果然和linux有很多不同，要多多請(qǐng)教了。

作者: zx_wing 時(shí)間: 2007-06-28 10:56

原帖由 xiaozhaoz 于 2007-6-27 22:36 發(fā)表于 21樓

簡(jiǎn)單看了一下前面的回復(fù), 不能認(rèn)同.

問題的焦點(diǎn)大家都集中在異步異常(中斷)沒有自己的上下文?

中斷搶占了當(dāng)前任務(wù)后, 可以通過current獲得當(dāng)前的task結(jié)構(gòu), 將當(dāng)前任務(wù)的寄存器信息壓入棧中, 替換成自 ...

此外，我想lz對(duì)上下文一詞還有點(diǎn)誤解。
上下文（context）表示當(dāng)前cpu的狀態(tài)，包括各種標(biāo)志及寄存器的值。這里中斷是運(yùn)行在自己的上下文而不是進(jìn)程的上下文。如果是運(yùn)行在進(jìn)程上下文的話，中斷處理就不需要在開始就保存上下文，在離開的時(shí)候又恢復(fù)。
當(dāng)然，有一些先進(jìn)的處理器（例如安騰），它為中斷處理程序提供了一套專門的寄存器供中斷處理程序使用，這個(gè)時(shí)候很多上下文是不需要保存的（但并非說就不保存上下文，只是某些不用保存）

作者: zx_wing 時(shí)間: 2007-06-28 10:58

原帖由 xiaozhaoz 于 2007-6-27 23:13 發(fā)表于 23樓

所見略同.

19樓描述的就是這個(gè)問題.

而realtime Patch解決的也是這個(gè)問題.

PS. 最近在做一個(gè)多內(nèi)核的項(xiàng)目, 包括solaris, 請(qǐng)問你們討論solaris內(nèi)核一般在哪里? OpenSolaris的mail list感覺不太熱鬧.

OpenSolaris？閣下是intel的？或是SUN北京分舵的？
如果不是，國(guó)內(nèi)也有公司開始做OpenSolaris了？

作者: 思一克 時(shí)間: 2007-06-28 11:05
中斷當(dāng)然有自己的CONTEXT。但沒有（準(zhǔn)確說經(jīng)常沒有）進(jìn)程相關(guān)的CONTEXT。
你看2.6.13 KERNEL，IRQ使用自己的STACK，如果在中斷中schedule()了，能正確回來嗎？

原帖由 zx_wing 于 2007-6-28 10:56 發(fā)表于 29樓

此外，我想lz對(duì)上下文一詞還有點(diǎn)誤解。
上下文（context）表示當(dāng)前cpu的狀態(tài)，包括各種標(biāo)志及寄存器的值。這里中斷是運(yùn)行在自己的上下文而不是進(jìn)程的上下文。如果是運(yùn)行在進(jìn)程上下文的話，中斷處理就不需要在 ...

作者: xiaozhaoz 時(shí)間: 2007-06-28 11:13

原帖由 zx_wing 于 2007-6-28 10:37 發(fā)表于 27樓

>>這其實(shí)和"中斷沒有自己的上下文"無關(guān). CPU沒有關(guān)中斷, 中斷有自己的上下文, 中斷的上下文就是搶占的任務(wù)A的上下文.

“中斷沒有自己的上下文”，呵呵，我沒有說這句話哈。lz很多立論在這 ...

中斷sleep了, 由誰來喚醒?
在關(guān)中斷的情況下, 不能sleep, 19樓已經(jīng)描述了.
在中斷handler中, 絕大部分都是開中斷的, 這個(gè)時(shí)候?yàn)槭裁床荒躶leep? 時(shí)鐘中斷可以正常觸發(fā), 要不中斷嵌套怎么實(shí)現(xiàn)? 當(dāng)然由時(shí)鐘中斷的軟中斷來喚醒. 如我說到的:
如果內(nèi)核修改好了, handler中調(diào)用schedule_timeout_interrupt().的情況.

中斷都很緊急, 這不一定正確,

不是所有的中斷handler都緊急, 就如solaris中描述的, 時(shí)鐘中斷最緊急, 其他的中斷不一定. 可能有的實(shí)時(shí)任務(wù)比中斷緊急.

中斷沒有上下文確實(shí)不是你說的, sorry.

作者: zx_wing 時(shí)間: 2007-06-28 11:15

原帖由 思一克 于 2007-6-28 11:05 發(fā)表于 31樓
中斷當(dāng)然有自己的CONTEXT。但沒有（準(zhǔn)確說經(jīng)常沒有）進(jìn)程相關(guān)的CONTEXT。
你看2.6.13 KERNEL，IRQ使用自己的STACK，如果在中斷中schedule()了，能正確回來嗎？

不好意思，我看貼也不仔細(xì)，把lz“總結(jié):
異步異常(中斷)handler不是沒有上下文, 而是沒有固定的上下文, 如果使用被搶占的任務(wù)作為上下文, 一,自身的處理無法得到實(shí)時(shí)保障,導(dǎo)致系統(tǒng)不確定性, 二,任務(wù)受到影響.”這句話看成中斷使用進(jìn)程上下文了。

作者: xiaozhaoz 時(shí)間: 2007-06-28 11:15

原帖由 思一克 于 2007-6-28 11:05 發(fā)表于 31樓
中斷當(dāng)然有自己的CONTEXT。但沒有（準(zhǔn)確說經(jīng)常沒有）進(jìn)程相關(guān)的CONTEXT。
你看2.6.13 KERNEL，IRQ使用自己的STACK，如果在中斷中schedule()了，能正確回來嗎？

你再編譯的時(shí)候, 把4K的stack的選項(xiàng)不要選上, 中斷和軟中斷就不會(huì)使用自己的棧, 而是使用被搶占任務(wù)的棧了.

所以棧不是中斷不能sleep的原因.

作者: zx_wing 時(shí)間: 2007-06-28 11:25

原帖由 xiaozhaoz 于 2007-6-28 11:13 發(fā)表于 32樓

中斷sleep了, 由誰來喚醒?
在關(guān)中斷的情況下, 不能sleep, 19樓已經(jīng)描述了.
在中斷handler中, 絕大部分都是開中斷的, 這個(gè)時(shí)候?yàn)槭裁床荒躶leep? 時(shí)鐘中斷可以正常觸發(fā), 要不中斷嵌套怎么實(shí)現(xiàn)? 當(dāng)然由時(shí)鐘中 ...

>>在中斷handler中, 絕大部分都是開中斷的, 這個(gè)時(shí)候?yàn)槭裁床荒躶leep? 時(shí)鐘中斷可以正常觸發(fā), 要不中斷嵌套怎么實(shí)現(xiàn)? 當(dāng)然由時(shí)鐘中斷的軟中斷來喚醒. 如我說到的:
如果內(nèi)核修改好了, handler中調(diào)用schedule_timeout_interrupt().的情況.
當(dāng)然，如果你把handler用內(nèi)核進(jìn)程來實(shí)現(xiàn)，當(dāng)然是可以睡眠和被調(diào)度的。這只是個(gè)實(shí)現(xiàn)問題。我這里的指的是linux下不能睡眠的原因。

>>中斷都很緊急, 這不一定正確,
緊急是個(gè)相對(duì)概念，我認(rèn)為中斷都比進(jìn)程緊急

作者: xiaozhaoz 時(shí)間: 2007-06-28 11:30

原帖由 zx_wing 于 2007-6-28 10:56 發(fā)表于 29樓

此外，我想lz對(duì)上下文一詞還有點(diǎn)誤解。
上下文（context）表示當(dāng)前cpu的狀態(tài)，包括各種標(biāo)志及寄存器的值。這里中斷是運(yùn)行在自己的上下文而不是進(jìn)程的上下文。如果是運(yùn)行在進(jìn)程上下文的話，中斷處理就不需要在 ...

nod, 在書里都是這樣寫的,
但是實(shí)際情況下比這個(gè)要復(fù)雜, 內(nèi)核中光有上下文無法完成調(diào)度切換的工作,

所以在Linux Kernel中, 我一般將上下文指作可以協(xié)助Kernel完成調(diào)度的東西, 就是內(nèi)核task, thread_info結(jié)構(gòu), + CPU寄存器.

[ 本帖最后由 xiaozhaoz 于 2007-6-28 11:32 編輯 ]

作者: xiaozhaoz 時(shí)間: 2007-06-28 11:35

原帖由 zx_wing 于 2007-6-28 11:25 發(fā)表于 35樓

>>在中斷handler中, 絕大部分都是開中斷的, 這個(gè)時(shí)候?yàn)槭裁床荒躶leep? 時(shí)鐘中斷可以正常觸發(fā), 要不中斷嵌套怎么實(shí)現(xiàn)? 當(dāng)然由時(shí)鐘中斷的軟中斷來喚醒. 如我說到的:
如果內(nèi)核修改好了, handler中調(diào)用sch ...

我想你還沒有真正理解我的意思, 19樓的總結(jié)說得很清楚, 中斷handler不能sleep,
不是因?yàn)闆]有"我說的上下文", 而是因?yàn)闆]有固定的上下文, 他會(huì)隨機(jī)搶占當(dāng)前任務(wù), 使用當(dāng)前任務(wù)的上下文作為調(diào)度單元. 既然有了調(diào)度單元, 他為什么不能sleep?

solaris12和我的想法差不多, 真正愿意那是調(diào)度問題和系統(tǒng)問題. 怎么解決這些問題, 就是19樓介紹的內(nèi)核實(shí)時(shí)性瓶頸的問題.

作者: augustusqing 時(shí)間: 2007-06-28 11:41
在中斷跟內(nèi)核用的是同一個(gè)棧的情況下，如果系統(tǒng)允許某個(gè)handler中可以sleep，那么在不可預(yù)知的任何時(shí)候，任何一個(gè)內(nèi)核線程/進(jìn)程在執(zhí)行的時(shí)候，恰好來了上面的中斷并執(zhí)行到了handler，則這個(gè)內(nèi)核線程/進(jìn)程就"中獎(jiǎng)"了，就會(huì)sleep，而只要這個(gè)handler是在開中的情況下運(yùn)行的，它是可以被其他線程/進(jìn)程喚醒的，關(guān)鍵是系統(tǒng)中所有的線程/進(jìn)程都有這個(gè)"中獎(jiǎng)"機(jī)會(huì)，哈哈

這樣理解對(duì)嗎？

[ 本帖最后由 augustusqing 于 2007-6-28 11:45 編輯 ]

作者: xiaozhaoz 時(shí)間: 2007-06-28 12:19

原帖由 augustusqing 于 2007-6-28 11:41 發(fā)表于 38樓
在中斷跟內(nèi)核用的是同一個(gè)棧的情況下，如果系統(tǒng)允許某個(gè)handler中可以sleep，那么在不可預(yù)知的任何時(shí)候，任何一個(gè)內(nèi)核線程/進(jìn)程在執(zhí)行的時(shí)候，恰好來了上面的中斷并執(zhí)行到了handler，則這個(gè)內(nèi)核線程/進(jìn)程就&quo ...

對(duì), 就是這個(gè)意思,
所以這種系統(tǒng)的不確定性就很大.
而現(xiàn)在的中斷除了不sleep, 不能preempt之外, 對(duì)任務(wù)的影響也想你說的那樣"中獎(jiǎng)"式的, 所以現(xiàn)在系統(tǒng)的實(shí)時(shí)性是無法保證的!!

解決這個(gè)問題的方法就是讓handler只能在固定的上下文中sleep, 當(dāng)然能不sleep最好不要sleep. 所以就有了將handler放到專門內(nèi)核線程中處理的想法.

如果內(nèi)核的實(shí)時(shí)性足夠好, 那么handler線程的執(zhí)行也可以得到保證.

作者: zx_wing 時(shí)間: 2007-06-28 12:38

原帖由 xiaozhaoz 于 2007-6-28 12:19 發(fā)表于 39樓

對(duì), 就是這個(gè)意思,
所以這種系統(tǒng)的不確定性就很大.
而現(xiàn)在的中斷除了不sleep, 不能preempt之外, 對(duì)任務(wù)的影響也想你說的那樣"中獎(jiǎng)"式的, 所以現(xiàn)在系統(tǒng)的實(shí)時(shí)性是無法保證的!!

解決這個(gè)問 ...

>>總結(jié): 異步異常(中斷)handler不是沒有上下文, 而是沒有固定的上下文, 如果使用被搶占的任務(wù)作為上下文, 一,自身的處理無法得到實(shí)時(shí)保障,導(dǎo)致系統(tǒng)不確定性, 二,任務(wù)受到影響.

linux是通用操作系統(tǒng)，并不是專門為嵌入式設(shè)計(jì)的實(shí)時(shí)操作系統(tǒng)，所以影響系統(tǒng)的實(shí)時(shí)性并不是中斷不能睡眠的原因。
誠(chéng)然，中斷不像進(jìn)程那樣有固定的上下文，所以它在linux中不是調(diào)度器的調(diào)度單位，所以不能睡眠，因?yàn)樗摺拘讯际钦{(diào)度器的任務(wù)，你不被調(diào)度器調(diào)度，當(dāng)然不能睡眠。如你所說，它是可以被實(shí)現(xiàn)成可睡眠的，但我這里講述的是它在linux中不能睡眠的原因。如果我的理解還不對(duì)的話，請(qǐng)lz再用一句總結(jié)一下在linux中中斷不能睡眠的原因。因?yàn)槟阄淖直容^多，我看的有點(diǎn)亂了。

[ 本帖最后由 zx_wing 于 2007-6-28 12:39 編輯 ]

作者: 思一克 時(shí)間: 2007-06-28 13:16
LZ發(fā)帖子是討論，不是有什么總結(jié)性的一句話能概括什么。我也是在學(xué)習(xí)中。

我覺得，LINUX設(shè)計(jì)不讓中斷中睡眠是經(jīng)過充分考慮的。seelp on interrupt（SOI）不允許是內(nèi)核設(shè)計(jì)的原因，而不是有什么絕對(duì)本質(zhì)的無法更改的原因。

我同意zx_wing的說法，沒有和進(jìn)程關(guān)聯(lián)的CONTEXT，而調(diào)度的基本單位是進(jìn)程，因此KERNEL設(shè)計(jì)者無法容忍sleep on interrrupt(SOI).

下面的相同的討論說的也很清楚：

think this should clear all confusions, apologies if this is too big
or irrelevant and doesnt make much sense, which I think is not the
case.

Note : The following explaination assumes that the isr and the
interrupted proceess share the stack, afaik isr can seperate stacks,
which is configurable, but I dont know how this explaination holds
good when the isr is having a seperate stack.

1. Why you are not allowed to sleep in an interrupt handler?Was this a
design decision or is there a fundamental reason that makes sleeping
interrupt handlers simply impossible? What about the page fault
handler - it (probably) sleeps when it has to swap in a page, why is
it possible to sleep for the page fault handler and not for an
interrupt handler?

-> Sleeping is implemented using scheduler. Scheduler only schedules
tasks (design decision to keep it simple). So you need a task context
to sleep in. Interrupt is not tied to a process (and uses stack of
whichever happens to be scheduled ) so it can't use the context
because it does not have to be in a sane state.

2. But why.....

You cannot sleep in an interrupt handler because interrupts do not have
a backing process context, and thus there is nothing to reschedule
back into. In other words, interrupt handlers are not associated with
a task, so there is nothing to "put to sleep" and (more importantly)
"nothing to wake up". They must run atomically.
The reason the page fault handler can sleep is that it is invoked only
by code that is running in process context. Because the kernel's own
memory is not pagable, only user-space memory accesses can result in a
page fault. Thus, only a few certain places (such as calls to
copy_{to,from}_user()) can cause a page fault within the kernel. Those
places must all be made by code that can sleep (i.e., process context,
no locks, etc).

3. However can't you consider the interrupt handler as running in the
context of the task A, that was incidentially running when the
interrupt occurred (the interrupt handler
uses the stack of task A, this is not always true, isr might have a
seperate stack). So wouldn't it conceptually be conceivable to put the
interrupt handler to sleep by saving the current CPU state (register
contents) with task A, putting task A asleep, and resume processing of
the interrupt once task A is rescheduled by the scheduler?
Of course this could be considered 'unfair' with respect to task A, in
that the interrupt has no relation to task A besides the fact that
they happend to be on the same CPU at the same time. But I am
interested in learning if there is any fundamental reason against
sleeping in an interrupt handler.

->There are bigger problems. The process is in an arbitrary state when
interrupt is invoked. So it might hold arbitrary spinlocks. It might
be on arbitrary wait_queues. Possibly other funny things might happen.
These either disallow sleeping or could interact badly with the
interrupt trying to sleep.

This is part of conversation happened on the same list before few
years, not verbatim though.
--

這里也說到了如果IRQ不用自己的STACK，而利用被中斷任務(wù)（任務(wù)A）的STACK是否就可以SOI了的問題。
因?yàn)橹袛喟l(fā)生的CONTEXT和A無關(guān)，而是碰巧在同一個(gè)CPU上的一個(gè)任務(wù)A被中斷了，如果中斷睡了，A就回被殃及，系統(tǒng)就徹底亂了。
（和調(diào)度發(fā)生沖突了）。

至于schedule()會(huì)將任務(wù)在不同CPU之間分，而IRQ回來后如何？（假定IRQ不使用自己的STACK，可以回來的話）。
還有最后一段說的其他各種復(fù)雜的問題。

總之，如果中斷不THREAD化，應(yīng)該無法SOI。所以LINUX（2。6）中shedule()中有檢查不允許。

如果改動(dòng)LINUX，如何改動(dòng)最小使得可以SOI？（雖然沒有大意義，但作為討論可以從討論中學(xué)習(xí)其他的）。

原帖由 zx_wing 于 2007-6-28 12:38 發(fā)表于 40樓

>>總結(jié): 異步異常(中斷)handler不是沒有上下文, 而是沒有固定的上下文, 如果使用被搶占的任務(wù)作為上下文, 一,自身的處理無法得到實(shí)時(shí)保障,導(dǎo)致系統(tǒng)不確定性, 二,任務(wù)受到影響.

linux是通用操作系統(tǒng) ...

作者: zx_wing 時(shí)間: 2007-06-28 13:59

原帖由 思一克 于 2007-6-28 13:16 發(fā)表于 41樓
LZ發(fā)帖子是討論，不是有什么總結(jié)性的一句話能概括什么。我也是在學(xué)習(xí)中。

我覺得，LINUX設(shè)計(jì)不讓中斷中睡眠是經(jīng)過充分考慮的。seelp on interrupt（SOI）不允許是內(nèi)核設(shè)計(jì)的原因，而不是有什么絕對(duì)本質(zhì)的無法 ...

我說的lz是xiaozhaoz兄，因?yàn)樗爬ǖ挠^點(diǎn)有點(diǎn)多，我看的不是很明白，所以想讓他總結(jié)一下。
呵呵，版主以為我在叫你啦

作者: 思一克 時(shí)間: 2007-06-28 14:04
LZ我認(rèn)為是說發(fā)帖子的人呀？

難到我理解錯(cuò)了。

原帖由 zx_wing 于 2007-6-28 13:59 發(fā)表于 42樓

我說的lz是xiaozhaoz兄，因?yàn)樗爬ǖ挠^點(diǎn)有點(diǎn)多，我看的不是很明白，所以想讓他總結(jié)一下。
呵呵，版主以為我在叫你啦

作者: xiaozhaoz 時(shí)間: 2007-06-28 14:25

原帖由 zx_wing 于 2007-6-28 13:59 發(fā)表于 42樓

我說的lz是xiaozhaoz兄，因?yàn)樗爬ǖ挠^點(diǎn)有點(diǎn)多，我看的不是很明白，所以想讓他總結(jié)一下。
呵呵，版主以為我在叫你啦

我個(gè)人的看法, 相信大家會(huì)有更多的想法.

一句話的總結(jié):
中斷sleep會(huì)導(dǎo)致系統(tǒng)工作異常.

三句話總結(jié):
1. 中斷sleep會(huì)增加任務(wù), 系統(tǒng)的不確定性
2. 和中斷共享中斷號(hào)的中斷會(huì)受到影響.
3. 中斷的處理受到被搶占任務(wù)上下文屬性的限制.

解釋和解決的方法看19樓.

總之, 我們都是在玩文字游戲, 中斷沒有固定上下文(context), 而不是沒有上下文.

PS, 正是因?yàn)長(zhǎng)inux是一個(gè)通用的操作系統(tǒng), 所以必須讓用戶可以配置成嵌入式實(shí)時(shí)模式, 所以必須考慮實(shí)時(shí)性因素!

作者: albcamus 時(shí)間: 2007-06-28 14:30
我怎么覺得你們3位彼此都懂對(duì)方說什么，只不過主張不同？

作者: 思一克 時(shí)間: 2007-06-28 14:51
我看了19樓的帖子，

覺得
中斷和軟中斷的線程化和spin_lock的可sleep化這兩個(gè)并不能提高系統(tǒng)的實(shí)時(shí)性。

比如spinlock, 就是為了短暫需要lock的時(shí)候讓CPU空等待。這時(shí)比用可以sleep的鎖要節(jié)省CPU而不是浪費(fèi)。因?yàn)檎{(diào)度的耗費(fèi)可能要比SPIN的耗費(fèi)多的多。

linux的中斷是半THREAD化的。你可以增加工作在THREAD（softirqd)中的比重，增加后，系統(tǒng)反映更慢了。比如你打一個(gè)字，一個(gè)網(wǎng)絡(luò)包的處理，如果都用THREAD做，響應(yīng)應(yīng)該是慢一些。因?yàn)檎{(diào)度的原因。

如果不對(duì)，請(qǐng)批駁。

[ 本帖最后由思一克于 2007-6-28 14:53 編輯 ]

作者: xiaozhaoz 時(shí)間: 2007-06-28 15:55

原帖由 思一克 于 2007-6-28 14:51 發(fā)表于 46樓
我看了19樓的帖子，

覺得
中斷和軟中斷的線程化和spin_lock的可sleep化這兩個(gè)并不能提高系統(tǒng)的實(shí)時(shí)性。

比如spinlock, 就是為了短暫需要lock的時(shí)候讓CPU空等待。這時(shí)比用可以sleep的鎖要節(jié)省CPU而不是浪 ...

好幾個(gè)同事問過同樣的問題.

這個(gè)問題已經(jīng)脫離了本貼的原意, 如果有興趣, 可以另外開貼討論.

實(shí)時(shí)性的必須保證, 系統(tǒng)在任何情況下, 可以在一定的時(shí)間內(nèi)執(zhí)行到某個(gè)任務(wù).

1. 你的比較尺度有問題, 你是拿現(xiàn)有系統(tǒng)的最好情況和realtime patch系統(tǒng)的最壞情況比較.
2. 現(xiàn)有系統(tǒng)的最壞情況, 延時(shí)可能有幾十毫秒, 察看19樓的描述. 而realtime patch的系統(tǒng)只有幾十us(不要低估了我們CPU的處理能力

, 而且上限制是可以計(jì)算的.

具體你可以在網(wǎng)上找到大量的測(cè)試報(bào)告.

[ 本帖最后由 xiaozhaoz 于 2007-6-28 16:53 編輯 ]

作者: 思一克 時(shí)間: 2007-06-28 17:11
LINUX中到是有中斷還沒有完全返回就調(diào)用schedule()而睡眠過去的例子。

可以猜是哪里。

作者: yangtou 時(shí)間: 2007-06-28 19:58
我覺得，中斷和異常不同，中斷是異步的，異常和系統(tǒng)調(diào)用是同步的。
異常比如缺頁異常發(fā)生時(shí)，當(dāng)前任務(wù)在異常處理完成之前不能繼續(xù)運(yùn)行，該異常處理過程和當(dāng)前任務(wù)天然相聯(lián)系，運(yùn)行在當(dāng)前進(jìn)程的上下文中。
中斷的發(fā)生很可能是與當(dāng)前任務(wù)無關(guān)的，如果把中斷處理實(shí)現(xiàn)為強(qiáng)行與當(dāng)前任務(wù)相關(guān)聯(lián)，就會(huì)造成當(dāng)前任務(wù)由于和他毫無關(guān)系的過程的執(zhí)行而被剝奪了運(yùn)行的權(quán)利。這樣的調(diào)度實(shí)現(xiàn)是不符合公平合理的原則的，是錯(cuò)誤的。

作者: zx_wing 時(shí)間: 2007-06-28 21:53

原帖由 albcamus 于 2007-6-28 14:30 發(fā)表于 45樓
我怎么覺得你們3位彼此都懂對(duì)方說什么，只不過主張不同？

恩，我也覺得其實(shí)大家心里都比較明白了，但表述不同而已。
我就此打住了。討論讓我收獲不少，謝謝大家。特別是solaris中那個(gè)IST讓我開眼界了。

作者: zx_wing 時(shí)間: 2007-06-28 21:56

原帖由 思一克 于 2007-6-28 14:04 發(fā)表于 43樓
LZ我認(rèn)為是說發(fā)帖子的人呀？

難到我理解錯(cuò)了。

你理解是對(duì)的，只是我不知道在引用了他人的回復(fù)后怎么稱呼對(duì)方。說閣下好像太酸了，說兄弟好像太魯莽了。沒這么個(gè)詞，叫貼主好了:em11:

作者: flw2 時(shí)間: 2007-06-28 22:04
看了這么多，我真沒完全看懂大家的帖子。當(dāng)時(shí)看書不知道為什么沒有想，可能是覺得理所當(dāng)然。

別把進(jìn)程看成有什么特殊好了，把它就是一個(gè)數(shù)據(jù)結(jié)構(gòu)。比如它要睡眠，就直接改變這個(gè)結(jié)構(gòu)的特征。然后別人能識(shí)別出來這個(gè)特征。而中斷也是改變這些數(shù)據(jù)結(jié)構(gòu)中的某些的特征，以便調(diào)度的時(shí)候能感知，而不是中斷的過程直接改變當(dāng)前進(jìn)程。這樣的結(jié)構(gòu)非常清晰，不會(huì)牽涉到太多的狀態(tài)轉(zhuǎn)換。這好像就是兩個(gè)上下文的區(qū)別了！進(jìn)程可以被中斷導(dǎo)致的搶占。如果實(shí)在很關(guān)鍵，那么它會(huì)禁止搶占。
代表進(jìn)程運(yùn)行的代碼地位和非進(jìn)程代碼的地位不一樣。后者是更核心的。

比如說假設(shè)進(jìn)程就是一個(gè)跳轉(zhuǎn)，然后必要時(shí)跳回來，這樣只要把跳回來的源指針放在源所在的結(jié)構(gòu)中（進(jìn)程內(nèi)核棧），就不用記住是從哪兒跳過來的，因?yàn)閷?shí)在太難記住了

作者: Solaris12 時(shí)間: 2007-06-28 23:11

原帖由 思一克 于 2007-6-28 14:51 發(fā)表于 46樓
我看了19樓的帖子，

比如spinlock, 就是為了短暫需要lock的時(shí)候讓CPU空等待。這時(shí)比用可以sleep的鎖要節(jié)省CPU而不是浪費(fèi)。因?yàn)檎{(diào)度的耗費(fèi)可能要比SPIN的耗費(fèi)多的多。

linux的中斷是半THREAD化的。你可以增加工作在THREAD（softirqd)中的比重，增加后，系統(tǒng)反映更慢了。比如你打一個(gè)字，一個(gè)網(wǎng)絡(luò)包的處理，如果都用THREAD做，響應(yīng)應(yīng)該是慢一些。因?yàn)檎{(diào)度的原因

1. Solaris的自適應(yīng)鎖比較聰明，發(fā)現(xiàn)有人已經(jīng)占用前就會(huì)去看鎖當(dāng)前的所有者是否在 CPU上運(yùn)行，如果是，就自旋，如果不是就睡眠。

2. Solaris的中斷線程是線程池，預(yù)先創(chuàng)建好的，kthread_t的結(jié)構(gòu)在中斷棧底部，總是就是為了減少線程化帶來的overhead。

作者: augustusqing 時(shí)間: 2007-06-29 10:50

原帖由 xiaozhaoz 于 2007-6-28 15:55 發(fā)表于 47樓

這個(gè)問題已經(jīng)脫離了本貼的原意, 如果有興趣, 可以另外開貼討論.

實(shí)時(shí)性的必須保證, 系統(tǒng)在任何情況下, 可以在一定的時(shí)間內(nèi)執(zhí)行到某個(gè)任務(wù).

1. 你的比較尺度有問題, ...

開吧開吧不是罪，再深的問題也能開貼討論清楚.

作者: zx_wing 時(shí)間: 2007-06-29 11:32

原帖由 Solaris12 于 2007-6-28 23:11 發(fā)表于 53樓

1. Solaris的自適應(yīng)鎖比較聰明，發(fā)現(xiàn)有人已經(jīng)占用前就會(huì)去看鎖當(dāng)前的所有者是否在 CPU上運(yùn)行，如果是，就自旋，如果不是就睡眠。

2. Solaris的中斷線程是線程池，預(yù)先創(chuàng)建好的，kthread_t的結(jié)構(gòu)在中斷 ...

Solaris上鎖的持有者可以睡眠？那死鎖怎么辦？

作者: Solaris12 時(shí)間: 2007-06-29 14:39

原帖由 zx_wing 于 2007-6-29 11:32 發(fā)表于 55樓

Solaris上鎖的持有者可以睡眠？那死鎖怎么辦？

我說的是自適應(yīng)鎖，Solaris的mutex本質(zhì)上分為自適應(yīng)和自旋兩種。

1.不允許睡眠的上下文要用自旋鎖，例如，IPI等高優(yōu)先級(jí)中斷。
2.允許睡眠的上下文用自適應(yīng)鎖，會(huì)動(dòng)態(tài)判斷自旋還是睡眠。一般低優(yōu)先級(jí)中斷用的就是這種鎖，例如網(wǎng)卡，磁盤等中斷。

作者: zx_wing 時(shí)間: 2007-06-29 15:05

原帖由 Solaris12 于 2007-6-29 14:39 發(fā)表于 56樓

我說的是自適應(yīng)鎖，Solaris的mutex本質(zhì)上分為自適應(yīng)和自旋兩種。

1.不允許睡眠的上下文要用自旋鎖，例如，IPI等高優(yōu)先級(jí)中斷。
2.允許睡眠的上下文用自適應(yīng)鎖，會(huì)動(dòng)態(tài)判斷自旋還是睡眠。一般低優(yōu)先級(jí) ...

慚愧慚愧，又沒看仔細(xì)，看成自旋鎖了。

作者: Au_Hank 時(shí)間: 2007-09-03 08:19
中斷本來就是用來處理緊急/突發(fā)事件的, 而進(jìn)程睡眠是因?yàn)闆]有事情可以做才去睡眠的,
兩者本來就屬于對(duì)立的情形. 所以,為什么要讓中斷處理程序去睡眠呢?

作者: folklore 時(shí)間: 2007-09-03 08:58
看了半天，頭都大了。這問題看一下操作系統(tǒng)的原理或設(shè)計(jì)類書就明白了。

1.中斷是可以睡眠的；如果你要這樣設(shè)計(jì)的話；

傳統(tǒng)UNIX：
2.中斷是沒有必要睡眠的，因?yàn)樗退羞M(jìn)程無關(guān)（事實(shí)上也有關(guān)，不然什么地方來的中斷，比如磁盤中斷總是和哪個(gè)讀寫磁盤的進(jìn)程有關(guān)的

）
3.更重要的是，它能很快完成，不睡眠被認(rèn)為能“充分利用資源”；

實(shí)時(shí)系統(tǒng):
4.在實(shí)時(shí)系統(tǒng)中，中斷應(yīng)當(dāng)被設(shè)計(jì)成能夠睡眠，并被高優(yōu)先級(jí)的進(jìn)程搶占；
5.中斷優(yōu)先級(jí)，是指2.中的相關(guān)進(jìn)程的優(yōu)先級(jí)；保存上下文不是問題，你可以將其設(shè)計(jì)成中斷任務(wù)（或線程）;
6.555，很難實(shí)現(xiàn).

作者: lalala 時(shí)間: 2007-12-03 15:54

原帖由 albcamus 于 2007-6-28 14:30 發(fā)表
我怎么覺得你們3位彼此都懂對(duì)方說什么，只不過主張不同？

有點(diǎn)像FREE BSD,LINUX,OPEN SOLARIS之間的關(guān)系。。。。

我覺得linux在將來的版本會(huì)實(shí)現(xiàn)kthread并把interrupt routine也歸入其中。
就像solaris。在進(jìn)程和進(jìn)程調(diào)度方面，solaris確實(shí)是走在前面。

并不是說把中斷以kthread形勢(shì)呈現(xiàn)就是為了調(diào)度它，而是在內(nèi)核真正抽象出thread概念。

作者: AIXHP 時(shí)間: 2007-12-03 16:29

原帖由 scutan 于 2007-6-27 09:38 發(fā)表

其實(shí)這只是一個(gè)設(shè)計(jì)上的問題, 而并不是強(qiáng)制的. 只是針對(duì)Linux內(nèi)核而言, 這是規(guī)矩.
LKD2上面說, 切換出去之后, 何時(shí)才能調(diào)度回來? 就是中斷回來之后可能不會(huì)回到之前所依俯的那個(gè)進(jìn)程了.
中斷不能睡眠 ...

睡眠是進(jìn)程調(diào)度的概念,中斷若睡眠上下文保持[進(jìn)程的概念]與中斷的概念沖突.要討論為何要睡眠?軟中斷中也不需要睡眠,可用不同分支處理不同情況,沒有睡眠的必要.完全可用網(wǎng)絡(luò)中CPU上下文保留一些緩沖等與睡眠有些類似.

[ 本帖最后由 AIXHP 于 2007-12-3 16:30 編輯 ]

作者: flw2 時(shí)間: 2007-12-27 09:59
如果spin_lock可以搶占, 一旦任務(wù)B搶占了任務(wù)A, 而任務(wù)A執(zhí)行了spin_lock(xxx), 恰好任務(wù)B也執(zhí)行spin_lock(xxx), 必然導(dǎo)致內(nèi)核死鎖.

不知為什么會(huì)＊死鎖＊

作者: osama123 時(shí)間: 2007-12-28 13:47
標(biāo)題: 回復(fù) #62 flw2 的帖子
你想為什么B搶占A?因?yàn)锽比A優(yōu)先級(jí)高，所以在此調(diào)度時(shí),A不會(huì)比B之前運(yùn)行,就不會(huì)釋放lock,那么B就一直等下去了唄。

作者: flw2 時(shí)間: 2007-12-28 16:22

原帖由 osama123 于 2007-12-28 13:47 發(fā)表
你想為什么B搶占A?因?yàn)锽比A優(yōu)先級(jí)高，所以在此調(diào)度時(shí),A不會(huì)比B之前運(yùn)行,就不會(huì)釋放lock,那么B就一直等下去了唄。

謝謝了
我以為還會(huì)有某個(gè)時(shí)候A得到運(yùn)行，這樣就不會(huì)死鎖了（即使這樣也是要禁止搶占的）。

作者: LF_532 時(shí)間: 2008-03-24 16:25
牛人，敬仰中...

mark，等以后知識(shí)加強(qiáng)后再來拜讀。

作者: jowvid 時(shí)間: 2009-11-25 14:29
很正點(diǎn)的一個(gè)問題。保留。

作者: hacktao 時(shí)間: 2009-11-29 08:39
過來學(xué)習(xí)下！

作者: EZWORD 時(shí)間: 2010-08-31 19:29
過來學(xué)習(xí)下！

作者: kaka11chen 時(shí)間: 2012-02-01 17:02
個(gè)人覺得是中斷嵌套的問題，ulk3里面也是這么解釋的。因?yàn)橹袛嗍褂玫膬?nèi)核棧無論是8k還是4k，都是每個(gè)CPU一個(gè)，而不是每個(gè)進(jìn)程一個(gè)。所以假如在執(zhí)行ISR的時(shí)候進(jìn)程切換了，接著切換后又在新的進(jìn)程執(zhí)行過程中被中斷，那么如果還是當(dāng)時(shí)的cpu那么那個(gè)中斷使用的內(nèi)核棧就又保存上下文，這時(shí)假如又發(fā)生進(jìn)程切換，切換回最開始的進(jìn)程，那么就無法找出當(dāng)時(shí)正確的中斷上下文了。最關(guān)鍵的問題我覺得就是不是每個(gè)進(jìn)程都有中斷相應(yīng)的內(nèi)核棧。這個(gè)應(yīng)該就是linux設(shè)計(jì)的問題。

作者: ljldx 時(shí)間: 2012-10-08 22:32
我是來看高手討論的

作者: lucasman 時(shí)間: 2012-10-10 16:53
看看 http://product.china-pub.com/301691
里面對(duì) 中斷可睡眠與否的解說吧。很清楚的。

5.1.3 中斷中斷中斷中斷和和和和異常的對(duì)比異常的對(duì)比異常的對(duì)比異常的對(duì)比
是否可睡眠是否可睡眠是否可睡眠是否可睡眠：由于異常為同步事件，由當(dāng)前進(jìn)程執(zhí)行所引發(fā)，所以可以說，異
常處于被打斷進(jìn)程的上下文之中，為當(dāng)前被打斷的進(jìn)程服務(wù)，所以在異常處理過程
中，可以調(diào)用任何內(nèi)核態(tài)的函數(shù)，也可以睡眠。因?yàn)樗邥r(shí)有意義的，同時(shí)也是合
理的；而中斷為異步事件，雖然使用當(dāng)前被打斷進(jìn)程的內(nèi)核棧、處于被打斷進(jìn)程的
上下文之中，但是和當(dāng)前被中斷進(jìn)程沒有必然的關(guān)系，同時(shí)中斷處理程序和外部的
一個(gè)具體設(shè)備相對(duì)應(yīng)，這就要求中斷處理程序能快速的完成，以便能及時(shí)地響應(yīng)設(shè)
備的下一次中斷請(qǐng)求，所以在中斷處理過程中是不可以睡眠的，也就是說終端處理
程序不能睡眠的根本原因在于中斷處理程序必須運(yùn)行的盡可能的快，以不丟失設(shè)備
的中斷請(qǐng)求。從另外的一個(gè)角度進(jìn)行考慮，假設(shè)中斷處理程序由于調(diào)用了一個(gè)可以
睡眠的內(nèi)核態(tài)函數(shù)，進(jìn)而睡眠了，那么被該中斷處理程序打斷的用戶進(jìn)程必定也隨
之睡眠，當(dāng)導(dǎo)致睡眠的原因消失后，那么喚醒被中斷處理程序所打斷的的用戶進(jìn)程
即可運(yùn)行睡眠的中斷處理程序。但是有兩點(diǎn)需要考慮：1：睡眠過程一定會(huì)丟失外設(shè)
的中斷請(qǐng)求。2：此時(shí)的中斷處理并不是為用戶進(jìn)程服務(wù)的，但是會(huì)將中斷處理程序
所使用的系統(tǒng)資源記賬到用戶進(jìn)程中去，這是不合理的；對(duì)比異常處理過程，因?yàn)?br /> 異常處理是為用戶進(jìn)程服務(wù)的，所以將異常處理過程所使用的系統(tǒng)資源記賬到用戶
進(jìn)程是合理的。

經(jīng)過上面的分析和討論，我們可以給出結(jié)果：異常處理過程可以睡眠；中斷處
理過程不可以睡眠。

回復(fù) 1# 思一克

作者: lucasman 時(shí)間: 2012-10-10 16:58
也就是說你可以讓中斷上半部處理過程中睡眠。但是你要考慮的后果，并做處理。

這樣會(huì)讓系統(tǒng)處理邏輯更復(fù)雜（要釋放相關(guān)的臨界資源）。

從另一個(gè)角度講，現(xiàn)在的上半部，下半部的劃分。就是為了實(shí)現(xiàn)中斷處理過程中可以調(diào)用的可能睡眠的函數(shù)。

lucasman 發(fā)表于 2012-10-10 16:53
看看 http://product.china-pub.com/301691
里面對(duì) 中斷可睡眠與否的解說吧。很清楚的。

作者: vsoloo 時(shí)間: 2013-03-11 17:10
金典討論～

作者: fengzheyu 時(shí)間: 2013-06-23 00:41
回復(fù) 16# 思一克

中斷用的不也是進(jìn)程的內(nèi)核棧嗎，這樣的話，當(dāng)這個(gè)進(jìn)程被重新調(diào)度的話，應(yīng)該可以繼續(xù)執(zhí)行中斷啊，

作者: fengzheyu 時(shí)間: 2013-06-23 02:57
讀完了，不知之前的幾位大牛現(xiàn)在都是干什么呢，這種討論貼子太好了，要是咱們國(guó)人都這個(gè)樣，牛b了

作者: _nosay 時(shí)間: 2016-02-16 16:14

ljldx 發(fā)表于 2012-10-08 22:32
我是來看高手討論的

我也是。

作者: jieniyisheng521 時(shí)間: 2016-02-17 22:22
最新ｌｉｎｕｘ內(nèi)核為保證任務(wù)的實(shí)時(shí)性，把中斷線程化，這樣中斷是可以睡眠的，也可以被搶占的．回復(fù) 1# 思一克

作者: mordorwww 時(shí)間: 2016-02-19 14:04
回復(fù) 19# xiaozhaoz

這個(gè)是什么意思，跟CFS有關(guān)？

如果realtime patch合并到主流內(nèi)核中, 可以滿足: 系統(tǒng)中優(yōu)先級(jí)高的任務(wù), 被**后, 在很小的可控的延時(shí)內(nèi), CS:eip指令得到執(zhí)行.

但不能保證低優(yōu)先級(jí)的時(shí)延, 這正是CFS要解決的問題, 設(shè)想一下, 要讓系統(tǒng)中的任何優(yōu)先級(jí)的任務(wù)在一定的時(shí)間內(nèi)得到執(zhí)行, 必然要求等待時(shí)間長(zhǎng)的任務(wù)優(yōu)先得到執(zhí)行, CFS就是用等待時(shí)間來作為調(diào)度的依據(jù), 而優(yōu)先級(jí)居次. 有時(shí)間在討論CFS的實(shí)現(xiàn).

作者: mordorwww 時(shí)間: 2016-02-19 14:55

思一克發(fā)表于 2007-06-28 17:11
LINUX中到是有中斷還沒有完全返回就調(diào)用schedule()而睡眠過去的例子。

可以猜是哪里。

挖墳
在哪里?

作者: mordorwww 時(shí)間: 2016-02-19 14:58

Au_Hank 發(fā)表于 2007-09-03 08:19
中斷本來就是用來處理緊急/突發(fā)事件的, 而進(jìn)程睡眠是因?yàn)闆]有事情可以做才去睡眠的,
兩者本來就屬于對(duì)立的 ...

進(jìn)程有活干也會(huì)被搶占阿
被內(nèi)核搶占
被其它進(jìn)程搶占

作者: mordorwww 時(shí)間: 2016-02-19 15:00
這個(gè)帖子的古人們出來繼續(xù)討論阿

歡迎光臨 Chinaunix (http://www.72891.cn/)