2012-04-26 49 views
5

Tôi đã viết một chương trình thử nghiệm chỉ bao gồm một vòng lặp vô hạn với một số tính toán bên trong và không thực hiện các hoạt động I/O . Tôi cố gắng bắt đầu từ hai trường hợp của chương trình, một với một giá trị giá trị nice cao, và khác với một giá trị giá trị nice thấp:Cài đặt mức độ ưu tiên (ưu tiên) không có hiệu lực trên Linux

sudo nice -n 19 taskset 1 ./test 
sudo nice -n -20 taskset 1 ./test 

Lệnh taskset đảm bảo rằng cả hai chương trình thực thi trên cùng một lõi. Trái với mong đợi của tôi, các báo cáo hàng đầu cho biết cả hai chương trình nhận được khoảng 50% thời gian tính toán . Tại sao vậy? Liệu lệnh tốt đẹp thậm chí có hiệu lực?

+0

các tính toán là gì? Có lẽ không có đủ tranh chấp trên bộ vi xử lý để tạo sự khác biệt – laher

+0

Các tính toán bên trong vòng lặp khá dài. Tôi cũng đã kiểm tra đầu ra của bộ tạo được tạo ra và không có gì được tối ưu hóa (được biên dịch với các cài đặt tối ưu hóa thấp nhất trên gcc). –

+0

có thể trùng lặp của [Hiểu renice] (http://stackoverflow.com/questions/22090126/understanding-renice) – ninjalj

Trả lời

1

Tôi giả định rằng có thiếu & ở cuối dòng lệnh. Nếu không, dòng thứ hai sẽ không chạy cho đến khi dòng đầu tiên hoàn thành.

Trong khi cả hai quá trình đang chạy, hãy sử dụng một cái gì đó như top và đảm bảo rằng chúng đều có giá trị tốt đẹp mà bạn đã gán.

Điều gì xảy ra nếu bạn khởi chạy các quá trình chỉ sử dụng taskset và sau đó điều chỉnh mức độ ưu tiên của chúng với renice sau khi chúng đang chạy?

+1

Vấn đề là tôi đang chạy các cá thể trong hai cửa sổ bảng điều khiển ở nền trước. Khi tôi chạy chúng trong nền (sử dụng &) nó hoạt động. Dường như các quy trình đặc quyền của Linux chạy trong nền trước trong một giao diện điều khiển và phần lớn (hoàn toàn?) Bỏ qua các giá trị độc đáo của chúng. Điều này có ý nghĩa khi người dùng có khả năng muốn tương tác với chương trình anh/cô ấy bắt đầu trong cửa sổ bảng điều khiển. –

+0

Bất kỳ làm rõ về cách thức hoạt động chính xác này sẽ được đánh giá cao. –

+0

Chạy một chương trình ở nền trước chạy nó như là một tiến trình con của giao diện điều khiển sinh ra nó, và các tiến trình con thường kế thừa ưu tiên của cha mẹ chúng. Việc thêm '&' chạy chương trình như là một quá trình hoàn toàn riêng biệt, cho phép bạn kiểm soát mức độ ưu tiên riêng của nó. – bta

2

Tôi đặt cùng một test.c rằng chỉ cần làm:

for(;;) 
    { 
    } 

Và sau đó chạy nó với tốt đẹp của bạn của. Tôi đã không chạy một sudo khác nhau cho mỗi một, mà là sudo'd một vỏ tương tác và chạy chúng cả từ đó. Tôi đã sử dụng hai số &.

Tôi có một ./test nhấn CPU của tôi khó khăn và chỉ chạm nhẹ vào nó.

Đương nhiên, hệ thống vẫn cảm thấy khá nhạy; phải mất rất nhiều quá trình CPU-hogging trên bộ vi xử lý hiện đại để có được tải rất nhiều, bạn có thể "cảm thấy" nó.

Điều đó tương phản với quy trình I/O-hogging và quy trình hoán đổi bộ nhớ; trong những trường hợp này, một quá trình tham lam duy nhất có thể làm cho hệ thống trở nên đau đớn khi sử dụng.

Tôi đoán hệ thống của bạn có lỗi liên quan đến ưu tiên tương đối duy nhất (hoặc tinh tế) hoặc có điều gì đó với phương pháp của bạn.

Tôi đã chạy thử nghiệm trên hệ thống Ubuntu 11.04.

+0

Khi tôi chạy cả hai quá trình trong nền nó cũng làm việc. Tôi cho rằng các quy trình đặc quyền của Linux mà người dùng có thể muốn tương tác (ví dụ: các chương trình bắt đầu từ bash và chạy ở nền trước) và phần lớn bỏ qua các giá trị độc đáo của chúng. –

1

Cài đặt độ ưu tiên quá trình (ưu tiên) CÓ hiệu lực trên Linux!(trong thực tế, nhưng chỉ khi bạn cung cấp cho nó đủ việc phải làm!)

Trên hệ thống của tôi, miễn là tất cả các lõi đang được nạp đầy đủ, sau đó thoải mái không có tác động. Trên ubuntu 14.04, quy trình chạy với nice -N được thông qua 0.807 ** N hoạt động so với các tiến trình chạy mà không thay đổi giá trị đẹp (cho dù bạn đang chạy một cá thể trên mỗi lõi cho mỗi cấp độ đẹp).

Trong trường hợp của tôi, tôi có lõi tứ i7 với luồng siêu tắt, vì vậy nếu tôi chạy bốn hoặc ít quy trình hơn, thì không quan trọng giá trị đẹp của chúng là gì - chúng đều có lõi đầy đủ. Nếu tôi chạy bốn quy trình ở cấp độ 0 và 4 ở mức 12 tốt đẹp, thì những cái ở cấp 12 nhận được thông qua 0,807^12, tức là khoảng 7% công việc những người ở mức độ tốt đẹp không làm.Tỷ lệ này có vẻ là một yếu tố dự đoán hợp lý từ mức 0 đến 14, sau đó nó biến động (Một vài chạy có mức xử lý 18 tốt đẹp hơn 16 ví dụ) - Chạy thử nghiệm lâu hơn có thể làm mịn kết quả.

(ruby 2.1.2 sử dụng)

, cl file:

uptime 
nices='-0 -6 -12 -18' 
nices='-0 -18' 
nices='-0 -2 -4 -6 -8 -10 -12 -14 -16 -18' 
rm -f ,n-* 
for i in 1 2 3 4 
do 
    for n in $nices 
    do 
    nice $n ruby ,count_loops.rb > ,n${n}-$i & 
    done 
done 
ps -l 
uptime 
wait 
uptime 
ps -l 
c=`cat ,n-0-[1234] | total` 
last=$c 
for n in $nices 
do 
    echo 
    c2=`cat ,n${n}-[1234] | total` 
    echo total of `cat ,n${n}-[1234]` is $c2 
    echo -n "nice $n count $2, percentage: " 
    echo "3 k $c2 100 * $c/p" | dc 
    echo -n "     percent of last: " 
    echo "3 k $c2 100 * $last/p" | dc 
    last=$c2 
done 
uptime 
echo total count: `cat ,n-*-[1234] | total` 

, file count_loops.rb

#!/usr/bin/env ruby 
limit = Time.new + 70 
i=0 
while Time.new < limit 
i += 1 
j = 0 
while (j += 1) < 10000 
    t = j 
end 
end 
puts i 

kết quả sh ,cl - đầu ra chẩn đoán ban đầu:

19:16:25 up 20:55, 2 users, load average: 3.58, 3.59, 2.88 
F S UID PID PPID C PRI NI ADDR SZ WCHAN TTY   TIME CMD 
0 S 1000 4987 4977 0 80 0 - 7297 wait pts/3 00:00:00 bash 
0 S 1000 11743 2936 0 80 0 - 2515 wait pts/3 00:00:00 rubymine.sh 
0 S 1000 11808 11743 6 80 0 - 834604 futex_ pts/3 00:18:10 java 
0 S 1000 11846 11808 0 80 0 - 4061 poll_s pts/3 00:00:02 fsnotifier64 
0 S 1000 19613 4987 0 80 0 - 2515 wait pts/3 00:00:00 sh 
0 R 1000 19616 19613 0 80 0 - 7582 -  pts/3 00:00:00 ruby 
0 R 1000 19617 19613 0 82 2 - 7582 -  pts/3 00:00:00 ruby 
0 R 1000 19618 19613 0 84 4 - 7582 -  pts/3 00:00:00 ruby 
0 R 1000 19619 19613 0 86 6 - 7416 -  pts/3 00:00:00 ruby 
0 R 1000 19620 19613 0 88 8 - 6795 -  pts/3 00:00:00 ruby 
0 R 1000 19621 19613 0 90 10 - 6247 -  pts/3 00:00:00 ruby 
0 R 1000 19622 19613 0 92 12 - 6247 -  pts/3 00:00:00 ruby 
0 R 1000 19623 19613 0 94 14 - 6247 -  pts/3 00:00:00 ruby 
0 R 1000 19624 19613 0 96 16 - 6078 -  pts/3 00:00:00 ruby 
0 R 1000 19625 19613 0 98 18 - 6012 -  pts/3 00:00:00 ruby 
0 R 1000 19626 19613 0 80 0 - 7582 -  pts/3 00:00:00 ruby 
0 R 1000 19627 19613 0 82 2 - 7582 -  pts/3 00:00:00 ruby 
0 R 1000 19628 19613 0 84 4 - 7582 -  pts/3 00:00:00 ruby 
0 R 1000 19629 19613 0 86 6 - 7582 -  pts/3 00:00:00 ruby 
0 R 1000 19630 19613 0 88 8 - 6247 -  pts/3 00:00:00 ruby 
0 R 1000 19631 19613 0 90 10 - 6247 -  pts/3 00:00:00 ruby 
0 R 1000 19632 19613 0 92 12 - 6247 -  pts/3 00:00:00 ruby 
0 R 1000 19633 19613 0 94 14 - 6144 -  pts/3 00:00:00 ruby 
0 R 1000 19634 19613 0 96 16 - 4971 -  pts/3 00:00:00 ruby 
0 R 1000 19635 19613 0 98 18 - 4971 -  pts/3 00:00:00 ruby 
0 R 1000 19636 19613 0 80 0 - 7582 -  pts/3 00:00:00 ruby 
0 R 1000 19637 19613 0 82 2 - 7449 -  pts/3 00:00:00 ruby 
0 R 1000 19638 19613 0 84 4 - 7344 -  pts/3 00:00:00 ruby 
0 R 1000 19639 19613 0 86 6 - 7582 -  pts/3 00:00:00 ruby 
0 R 1000 19640 19613 0 88 8 - 7416 -  pts/3 00:00:00 ruby 
0 R 1000 19641 19613 0 90 10 - 6210 -  pts/3 00:00:00 ruby 
0 R 1000 19642 19613 0 92 12 - 6247 -  pts/3 00:00:00 ruby 
0 R 1000 19643 19613 0 94 14 - 5976 -  pts/3 00:00:00 ruby 
0 R 1000 19644 19613 0 96 16 - 6111 -  pts/3 00:00:00 ruby 
0 R 1000 19645 19613 0 98 18 - 4971 -  pts/3 00:00:00 ruby 
0 R 1000 19646 19613 0 80 0 - 7582 -  pts/3 00:00:00 ruby 
0 R 1000 19647 19613 0 82 2 - 7516 -  pts/3 00:00:00 ruby 
0 R 1000 19648 19613 0 84 4 - 7416 -  pts/3 00:00:00 ruby 
0 R 1000 19649 19613 0 86 6 - 6247 -  pts/3 00:00:00 ruby 
0 R 1000 19650 19613 0 88 8 - 6177 -  pts/3 00:00:00 ruby 
0 R 1000 19651 19613 0 90 10 - 6247 -  pts/3 00:00:00 ruby 
0 R 1000 19652 19613 0 92 12 - 6078 -  pts/3 00:00:00 ruby 
0 R 1000 19653 19613 0 94 14 - 6247 -  pts/3 00:00:00 ruby 
0 R 1000 19654 19613 0 96 16 - 4971 -  pts/3 00:00:00 ruby 
0 R 1000 19655 19613 0 98 18 - 4971 -  pts/3 00:00:00 ruby 
0 R 1000 19656 19613 0 80 0 - 3908 -  pts/3 00:00:00 ps 
19:16:26 up 20:55, 2 users, load average: 3.58, 3.59, 2.88 
19:17:37 up 20:56, 3 users, load average: 28.92, 11.25, 5.59 
F S UID PID PPID C PRI NI ADDR SZ WCHAN TTY   TIME CMD 
0 S 1000 4987 4977 0 80 0 - 7297 wait pts/3 00:00:00 bash 
0 S 1000 11743 2936 0 80 0 - 2515 wait pts/3 00:00:00 rubymine.sh 
0 S 1000 11808 11743 6 80 0 - 834604 futex_ pts/3 00:18:10 java 
0 S 1000 11846 11808 0 80 0 - 4061 poll_s pts/3 00:00:02 fsnotifier64 
0 S 1000 19613 4987 0 80 0 - 2515 wait pts/3 00:00:00 sh 
0 R 1000 19794 19613 0 80 0 - 3908 -  pts/3 00:00:00 ps 

kết quả sh ,cl - thống kê: (tỷ lệ cuối cùng là tỷ lệ phần trăm của tổng số này so với số lượng cho nhóm cuối cùng của quá trình)

total of 99951 101725 100681 104046 is 406403 
nice -0 count , percentage: 100.000 
        percent of last: 100.000 

total of 64554 62971 64006 63462 is 254993 
nice -2 count , percentage: 62.743 
        percent of last: 62.743 

total of 42997 43041 43197 42717 is 171952 
nice -4 count , percentage: 42.310 
        percent of last: 67.434 

total of 26882 28250 27151 27244 is 109527 
nice -6 count , percentage: 26.950 
        percent of last: 63.696 

total of 17228 17189 17427 17769 is 69613 
nice -8 count , percentage: 17.129 
        percent of last: 63.557 

total of 10815 10792 11021 11307 is 43935 
nice -10 count , percentage: 10.810 
        percent of last: 63.113 

total of 7023 6923 7885 7323 is 29154 
nice -12 count , percentage: 7.173 
        percent of last: 66.357 

total of 5005 4881 4938 5159 is 19983 
nice -14 count , percentage: 4.917 
        percent of last: 68.542 

total of 3517 5537 3555 4092 is 16701 
nice -16 count , percentage: 4.109 
        percent of last: 83.576 

total of 4372 4307 5552 4527 is 18758 
nice -18 count , percentage: 4.615 
        percent of last: 112.316 
19:17:37 up 20:56, 3 users, load average: 28.92, 11.25, 5.59 
total count: 1141019 

(Purists sẽ lưu ý Tôi trộn ruby, vỏ và dc - họ sẽ phải tha thứ cho tôi vì những thói quen cũ từ thế kỷ trước cho thấy thông qua;))

3

Hành vi bạn thấy gần như chắc chắn vì tính năng tự động nhóm được thêm vào trong Linux 2.6.38 (trong năm 2010). Có lẽ khi bạn mô tả chạy hai lệnh, chúng được chạy trong các cửa sổ thiết bị đầu cuối khác nhau. Nếu bạn đã chạy chúng trong cùng một cửa sổ thiết bị đầu cuối, thì bạn sẽ thấy giá trị đẹp có hiệu lực. Phần còn lại của câu trả lời này làm rõ câu chuyện.

Hạt nhân cung cấp tính năng được gọi là autogrouping để cải thiện hiệu suất máy tính để bàn tương tác khi xử lý đa nhân, khối lượng công việc của CPU chẳng hạn như xây dựng hạt nhân Linux với số lượng lớn quy trình xây dựng song song (ví dụ: cờ make(1) -j).

Nhóm tự động mới được tạo khi phiên mới được tạo qua setsid(2); điều này xảy ra, ví dụ, khi một cửa sổ terminal mới được khởi động. Một quy trình mới được tạo bởi fork(2) kế thừa số thành viên tự động của nhóm phụ huynh là . Do đó, tất cả các quy trình trong phiên là các thành viên của cùng một nhóm tự động.

Khi bật tính năng tự động nhóm, tất cả các thành viên của nhóm tự động được đặt trong cùng một nhóm tác vụ lên lịch hạt nhân ". Trình lập lịch biểu hạt nhân Linux sử dụng một thuật toán cân bằng sự phân bố của các chu kỳ CPU trên các nhóm nhiệm vụ. Những lợi ích của việc này cho hiệu suất máy tính để bàn tương tác có thể được mô tả qua ví dụ sau.

Giả sử rằng có hai autogroups cạnh tranh cho cùng một CPU (ví dụ, giả sử một trong hai hệ thống CPU đơn hoặc việc sử dụng taskset(1) để nhốt tất cả các quá trình với cùng CPU trên một hệ thống SMP). Nhóm đầu tiên chứa mười quy trình liên kết CPU từ hạt nhân bắt đầu với make -j10. Cái còn lại chứa một quá trình liên kết CPU : trình phát video. Ảnh hưởng của tự động nhóm là hai nhóm sẽ nhận được một nửa chu kỳ CPU. Tức là, trình phát video sẽ nhận được 50% chu kỳ CPU, thay vì chỉ 9% chu kỳ, điều này có khả năng sẽ dẫn đến việc phát lại video bị thoái hóa .Tình hình trên hệ thống SMP phức tạp hơn, nhưng hiệu ứng chung giống nhau: bộ lập lịch phân phối các chu kỳ CPU trên các nhóm nhiệm vụ sao cho một nhóm tự động có số lượng lớn các quy trình ràng buộc CPU không kết thúc việc hoán đổi chu trình CPU với chi phí của các công việc khác trên hệ thống.

Giá trị tốt đẹp và lịch nhóm

Khi lên kế hoạch quá trình phi thời gian thực (ví dụ, những người lên kế hoạch theo chính sách mặc định SCHED_OTHER), các scheduler sử dụng một kỹ thuật gọi là "lịch trình nhóm", theo chủ đề nào được lên lịch trong "nhóm tác vụ". Các nhóm tác vụ được hình thành trong các trường hợp khác nhau, với trường hợp có liên quan ở đây là tự động nhóm.

Nếu autogrouping được kích hoạt, sau đó tất cả các chủ đề được (ngầm) được đặt trong một autogroup (ví dụ, cùng một phiên, như tạo ra bởi setsid(2)) tạo thành một nhóm nhiệm vụ. Mỗi nhóm tự động mới là do đó, một nhóm nhiệm vụ riêng biệt.

Theo lịch trình nhóm, giá trị đẹp của một chủ đề có tác dụng cho quyết định lập kế hoạch chỉ liên quan đến chủ đề khác trong cùng nhóm nhiệm vụ. Điều này có một số hậu quả đáng ngạc nhiên về mặt ngữ nghĩa truyền thống của một giá trị tốt đẹp trên các hệ thống UNIX là . Đặc biệt, nếu bật tính năng tự động nhóm (mặc định trong các bản phân phối Linux khác nhau), thì sử dụng nice(1) trên quy trình chỉ có hiệu lực để lên lịch tương ứng với các quy trình khác được thực hiện trong cùng một phiên. .

Ngược lại, đối với hai quá trình được (ví dụ) duy nhất quá trình CPU-bound trong phiên khác nhau (ví dụ, khác nhau terminal cửa sổ, mỗi người có công việc được gắn với autogroups khác nhau), sửa đổi giá trị tốt đẹp của quá trình tại một trong các phiên có không có hiệu lực về các quyết định của lịch trình liên quan đến quy trình trong phiên khác. Đây có lẽ là kịch bản bạn thấy, mặc dù bạn không đề cập rõ ràng bằng cách sử dụng hai cửa sổ đầu cuối.

Nếu bạn muốn ngăn chặn autogrouping can thiệp vào nice hành vi truyền thống như mô tả ở đây, bạn có thể tắt tính năng

echo 0 > /proc/sys/kernel/sched_autogroup_enabled 

Hãy nhận biết mặc dù rằng điều này cũng sẽ có tác dụng vô hiệu hóa những lợi ích cho tương tác máy tính để bàn tính năng autogroup được dự định cung cấp (xem ở trên).

Các autogroup giá trị đẹp

thành viên autogroup của một quá trình có thể được xem qua file /proc/[pid]/autogroup:

$ cat /proc/1/autogroup 
/autogroup-1 nice 0 

Tập tin này cũng có thể được sử dụng để thay đổi băng thông CPU phân bổ một autogroup . Điều này được thực hiện bằng cách viết một số trong phạm vi "đẹp" vào tệp để đặt giá trị đẹp của nhóm tự động. Phạm vi cho phép là từ +19 (mức độ ưu tiên thấp) đến -20 (mức độ ưu tiên cao).

Các autogroup khung cảnh đẹp có ý nghĩa tương tự như quá trình giá trị tốt đẹp, nhưng áp dụng cho phân phối của chu kỳ CPU đến autogroup như một toàn thể, dựa trên các giá trị đẹp tương đối của autogroups khác. Đối với một quá trình bên trong một autogroup, CPU chu kỳ rằng nó nhận sẽ là một sản phẩm của giá trị tốt đẹp của autogroup (so sánh với các nhóm khác) và giá trị tốt đẹp của quá trình (so với các quy trình khác trong cùng một nhóm).

Các vấn đề liên quan