Hiểu liên kết giữa CONFIG_SMP, Spinlocks và CONFIG_PREEMPT trong hạt nhân Linux mới nhất (3.0.0 trở lên)

Question

Để cung cấp cho bạn ngữ cảnh đầy đủ, cuộc thảo luận của tôi bắt đầu với quan sát rằng tôi đang chạy một SMP linux (3.0.1-rt11) trên vỏ ARM A8 dựa trên SoC mà là một uniprocessor. Tôi đã tò mò muốn biết nếu có bất kỳ lợi thế hiệu suất nào bằng cách vô hiệu hóa hỗ trợ SMP. Và nếu có những gì tác động nó sẽ có trên trình điều khiển của tôi và xử lý ngắt.

Tôi đã thực hiện một số việc đọc và tìm hiểu hai chủ đề liên quan: khóa spinlocks và phần thưởng hạt nhân. Tôi đã ít googling và đọc nhưng lần này tất cả tôi đã nhận được vài câu trả lời cũ và mâu thuẫn. Vì vậy, tôi nghĩ hãy để tôi thử stackoverflow.

Xuất xứ của những nghi ngờ của tôi/câu hỏi là para này từ trình điều khiển thiết bị Linux 3rd edition chương 5:

spinlocks được, bởi bản chất của họ, mục đích để sử dụng trên đa hệ thống, mặc dù một máy trạm uniprocessor chạy một preemptive hạt nhân hoạt động như SMP, khi có liên quan đến đồng thời. Nếu hệ thống uniprocessor không được kiểm soát bao giờ đi vào vòng quay trên một khóa, nó sẽ quay mãi mãi; không có chủ đề nào khác có thể có được CPU để giải phóng khóa. Vì lý do này, các hoạt động spinlock trên các hệ thống uniprocessor không được kích hoạt tính năng ưu tiên được tối ưu hóa để làm không có gì, ngoại trừ những thay đổi về mặt nạ IRQ . Do việc sử dụng, ngay cả khi bạn không bao giờ mong đợi mã của mình là chạy trên hệ thống SMP, bạn vẫn cần triển khai khóa thích hợp.

nghi ngờ của tôi/câu hỏi là:

a) là Linux kernel ưu tiên trong vũ trụ hạt nhân theo mặc định? Nếu có, tiền thưởng này có giới hạn cho các quy trình duy nhất hay trình xử lý ngắt cũng có thể được ưu tiên không?

b) Hạt nhân Linux (trên ARM) có hỗ trợ ngắt lồng nhau không? Nếu có, thì mỗi trình xử lý ngắt (nửa trên) có ngăn xếp riêng hoặc chúng có cùng một ngăn xếp chế độ hạt nhân 4k/8k không?

c) Nếu tôi tắt SMP (Config_SMP) và tiền thưởng (Config_preempt) sẽ quay vòng trong trình điều khiển của tôi và trình xử lý ngắt có ý nghĩa gì không?

d) Làm thế nào xử lý hạt nhân ngắt tăng lên trong khi thực hiện nửa đầu tức là chúng sẽ bị vô hiệu hóa hoặc bị che khuất?

Sau khi một số googling Tôi thấy điều này:

Đối với hạt nhân biên soạn mà không CONFIG_SMP, và không có CONFIG_PREEMPT spinlocks không tồn tại. Đây là một quyết định thiết kế tuyệt vời: khi không ai khác có thể chạy cùng một lúc, không có lý do gì để có một khóa.

Nếu kernel được biên dịch mà không CONFIG_SMP, nhưng CONFIG_PREEMPT là bộ, sau đó spinlocks chỉ đơn giản là vô hiệu hóa đòn phủ đầu, đó là đủ để ngăn chặn bất kỳ cuộc đua. Đối với hầu hết các mục đích, chúng tôi có thể nghĩ về việc mua trước là tương đương với SMP và không phải lo lắng về điều này một cách riêng biệt.

Nhưng không có phiên bản hạt nhân hoặc ngày trên source.Bất cứ ai có thể xác nhận nếu nó vẫn còn hợp lệ cho hạt nhân Linux mới nhất?

Answer 1

a) Cho dù Linux có được ưu tiên hay không phụ thuộc vào việc bạn có định cấu hình theo cách đó hay không, bạn có thể định cấu hình theo cách đó hay không
với CONFIG_PREEMPT. Không có mặc định. Nếu bạn chạy make config, bạn sẽ phải chọn.

b) Ngắt làm tổ trên Linux; trong khi các ngắt đang được xử lý, các ngắt khác có thể tắt. Điều đó đúng trên ARM và nhiều kiến ​​trúc khác. Đó là tất cả trên cùng một ngăn xếp. Tất nhiên, ngăn xếp không gian người dùng không được sử dụng cho các ngắt!

c) Nếu bạn vô hiệu hóa SMP và tiền thưởng, spinlocks trong mã của bạn sẽ giảm xuống không-op nếu chúng là spinlocks thông thường và IRQ spinlocks (spin_lock_irqsave/spin_lock_irqrestore) sẽ biến thành vô hiệu hóa/bật. Cái thứ hai vẫn còn cần thiết, do đó; chúng ngăn chặn các cuộc đua giữa các công việc chạy mã của bạn và ngắt chạy mã của bạn.

d) "Nửa đầu" theo truyền thống đề cập đến các gián đoạn dịch vụ. Mã nửa trên của trình điều khiển được điều hành bởi các ngắt. Nửa dưới được gọi bằng công việc (để đọc hoặc ghi dữ liệu hoặc bất kỳ thứ gì). Chi tiết về xử lý ngắt là kiến ​​trúc cụ thể.

Gần đây nhất tôi đã làm việc rất chặt chẽ với các ngắt Linux trên kiến ​​trúc MIPS cụ thể. Trên bảng đặc biệt đó, có 128 đường ngắt có thể che dấu được thông qua hai từ 64 bit. Hạt nhân đã thực hiện một lược đồ ưu tiên trên đầu trang này, vì vậy trước khi thực hiện một trình xử lý cho một ngắt đã cho, các phần tử thấp hơn được che dấu thông qua các bản cập nhật của các thanh ghi bit 2x64 đó. Tôi đã thực hiện một sửa đổi để các ưu tiên ngắt có thể được thiết lập tùy ý, thay vì theo vị trí phần cứng và tự động bằng cách viết các giá trị vào mục nhập /proc. Hơn nữa, tôi đặt trong một hack theo đó một phần của ưu tiên IRQ số chồng lên nhau với ưu tiên thời gian thực của nhiệm vụ. Vì vậy, nhiệm vụ RT (tức là không gian người dùng chủ đề) được giao cho một số mức độ ưu tiên nhất định đã có thể ngầm ẩn một loạt các ngắt nhất định trong khi chạy. Điều này rất hữu ích trong việc ngăn chặn các gián đoạn bị gián đoạn do các tác vụ quan trọng (ví dụ, một thường trình dịch vụ ngắt trong mã trình điều khiển IDE được sử dụng cho flash nhỏ gọn, thực hiện các vòng bận do giao diện phần cứng được thiết kế xấu, Vì vậy, dù sao, hành vi che giấu IRQ không được viết bằng đá, nếu bạn kiểm soát hạt nhân được sử dụng bởi khách hàng.

Các trích dẫn tuyên bố trong câu hỏi là chỉ đúng về spinlocks thường xuyên (spin_lock chức năng/macro) không spinlocks IRQ (spin_lock_irqsave). Trong một hạt nhân preemptible trên một uniprocessor, spin_lock chỉ cần vô hiệu hóa preemption, đó là đủ để giữ tất cả các nhiệm vụ khác ra khỏi hạt nhân cho đến khi spin_unlock. Nhưng spin_lock_irqsave phải tắt ngắt.