আমার প্রাথমিক ধারণাটি হ'ল যখন কোনও প্রক্রিয়া কেবলমাত্র সীমাবদ্ধ কারণগুলি ডিস্ক এবং সিপিইউ হয়, তারপরে মোট সিস্টেম "আইওয়েট" + সিপিইউ ব্যবহার একটি লজিক্যাল সিপিইউ এর কমপক্ষে 100% সমান হওয়া উচিত। (অন্যান্য ক্ষেত্রে এটি ধরে রাখবে না Eg যেমন ব্যবহার করে কোনও ফাইল ডাউনলোড wgetকরার সময় নেটওয়ার্কটি প্রায়শই সীমাবদ্ধ ফ্যাক্টর হয়)।

এই অনুমানটি একটি সাধারণ পরীক্ষা দ্বারা লঙ্ঘিত হয়। এটি কি প্রত্যাশিত? যদি এটি প্রত্যাশিত হয় তবে শর্তগুলির এমন একটি সেট রয়েছে যেখানে আমার অনুমানটি সত্য বলে আশা করা উচিত ?

এখানে "আইওয়েট" সম্পর্কে কিছু পটভূমি রয়েছে: একটি সিপিইউ কীভাবে জানতে পারে যে সেখানে আইও মুলতুবি রয়েছে? উত্তর এখানে পাল্টা স্বজ্ঞাত ধারণাটি উদ্ধৃত করে, যে ক্রমবর্ধমান আইওয়েট "কিছু পরিস্থিতিতে কমে যেতে পারে"। আমি ভাবছি যে আমার সাধারণ পরীক্ষাটি যদি এইরকম একটি অননুমোদিত অবস্থাকে ট্রিগার করতে পারে?

আপডেট : দয়া করে উত্তর এড়িয়ে যান ।

উত্তরটি আমি প্রাথমিকভাবে ব্যবহার করেছি তার চেয়ে সহজ পরীক্ষা রয়েছে। আমি নীচের মূল প্রশ্নটি সংরক্ষণ করেছি। মূল প্রশ্নটি কিছু অতিরিক্ত বিবরণ দেখাতে পারে।

আসল প্রশ্ন

সংক্ষিপ্ত পরীক্ষায়, আমি ddকার্নেলটিকে এলোমেলো বাইট তৈরির অনুরোধ জানাতে এবং সেগুলি একটি ফাইলে লিখতে ব্যবহার করি। আমি ddকমান্ডটি চালাচ্ছি perf stat, কেবল কার্নেলের অভ্যন্তরে সিপিইউ সময় কাটানোর জন্য একটি গণনা পেতে। আমি ভিতরে চালিত perf trace -sসময়টি রিপোর্ট করার জন্য এটি ভিতরে চালাও write()। একই সাথে, আমি vmstat 5অন্য টার্মিনালে চালিত , সিস্টেমটি "আইওয়েট" দেখতে।

আমি প্রত্যাশা করেছিলাম আমি কমপক্ষে একটি সম্পূর্ণ সিপিইউ "নন-ইডল" হিসাবে দেখতে পাব, অর্থাৎ এটি চলমান সময়ের 100% বা থামিয়ে দেওয়া হবে তবে আইও ("আইওয়েট" রাজ্যের) জন্য অপেক্ষা করছে। এটা ছিল না.
(এছাড়াও, আমি "আইওয়েট" সময়টি লেখার সময় ব্যয় করা সময়ের সাথে মোটামুটিভাবে মিলিয়ে দেখার আশা করছিলাম)) তবে এটি তেমনটি দেখা যায়নি।)

বিস্তারিত ফলাফল এবং পরীক্ষার পরিবেশ নীচে দেখানো হয়েছে। এছাড়াও দেখানো হচ্ছে একটি বিকল্প পরীক্ষা, যেখানে আমার অনুমানটি ধারণ করেছে did দ্রষ্টব্য: এটি অন্যদিকে নয়, perf statভিতরে চালানো দরকার ছিল perf trace। এটি এখানে বিশদভাবে বর্ণনা করা হয়েছে: "পারফ স্ট্যাস" (এবং "সময়"!) "পারফেক্ট ট্রেস - গুলি" চালানোর সময় কি ভুল ফলাফল দেখায়?

"আইওয়ায়েট" এর পটভূমি তথ্য

sarম্যানপেজ থেকে নেওয়া সংজ্ঞাটি নিম্নলিখিত :

% Iowait:

সিপিইউ বা সিপিইউগুলি নিষ্ক্রিয় থাকাকালীন সময়ের শতাংশের সময়কালে সিস্টেমটির একটি অসামান্য ডিস্ক I / O অনুরোধ ছিল।

সুতরাং,% আইওয়েট মানে সিপিইউ দৃষ্টিকোণ থেকে কোনও কাজ চলমান ছিল না, তবে কমপক্ষে একটি আই / ও চলছে। আইওয়ায়েট কেবল অলস সময়ের একটি ফর্ম যখন কোনও কিছুই নির্ধারিত করা যায় না। মান একটি পারফরম্যান্স সমস্যার ইঙ্গিত করতে কার্যকর হতে পারে বা নাও হতে পারে, তবে এটি ব্যবহারকারীকে বলে যে সিস্টেমটি নিষ্ক্রিয় এবং আরও কাজ করতে পারে।

https://support.hpe.com/hpsc/doc/public/display?docId=c02783994

এখানে আরও দীর্ঘ নিবন্ধ রয়েছে: বোঝা যাচ্ছে I / O অপেক্ষা (বা কেন 0% নিষ্ক্রিয়তা ঠিক হতে পারে) । এটি আপনাকে কীভাবে কার্নেল কোড থেকে সংজ্ঞাটি পরিষ্কারভাবে দেখতে পাবে তা ব্যাখ্যা করে। কোডটি কিছুটা পরিবর্তিত হয়েছে, তবে ধারণাটি এখনও স্পষ্ট:

/*
 * Account for idle time.
 * @cputime: the CPU time spent in idle wait
 */
void account_idle_time(u64 cputime)
{
    u64 *cpustat = kcpustat_this_cpu->cpustat;
    struct rq *rq = this_rq();

    if (atomic_read(&rq->nr_iowait) > 0)
        cpustat[CPUTIME_IOWAIT] += cputime;
    else
        cpustat[CPUTIME_IDLE] += cputime;
}

নিবন্ধটি একটি একক-সিপিইউ সিস্টেমে বিভিন্ন সম্পর্কিত পরীক্ষা-নিরীক্ষাও দেখায়। পরীক্ষায় কিছু এমনকি ব্যবহার ddসঙ্গে if=/dev/urandom ! তবে পরীক্ষাগুলিতে আমার পরীক্ষা অন্তর্ভুক্ত নয় dd if=/dev/urandom of=test.out । এটি কেবল ব্যবহার করে dd if=/dev/urandom of=/dev/null ।

"আইও ওয়েটার" এখন চিন্তা করা আরও জটিল কারণ আমরা বহু-সিপিইউ সিস্টেম ব্যবহার করি তবে আমার মনে হয় উদ্ধৃত কোডের ভিত্তিতে আমি এখনও এটি বুঝতে পেরেছি।

পরিবেশ

আমার চারটি লজিকাল সিপিইউ রয়েছে।

আমি LVM, এবং ext4 ফাইল সিস্টেম ব্যবহার করি। আমি আমার ডিস্ক বা ফাইল সিস্টেমে কোনও এনক্রিপশন ব্যবহার করছি না। আমার কোনও নেটওয়ার্ক ফাইলসিস্টেম মাউন্ট করা নেই, তাই আমি কোনও নেটওয়ার্ক ফাইল সিস্টেম পড়ছি বা লিখছি না।

নীচের ফলাফলগুলি আইও সিডিউলার 4.20.15-200.fc29.x86_64ব্যবহার করে কার্নেল থেকে এসেছে noop। cfqআই নির্ধারণকারী এছাড়াও অনুরূপ ফলাফল দেয়।

(আমিও কার্নেল বিল্ডে অনুরূপ ফলাফল দেখেছি যা একই ধরণের কনফিগারেশনের উপর ভিত্তি করে তৈরি হয়েছিল, তবে কার্নেল সংস্করণ 5.1 এর কাছাকাছি ছিল এবং ব্যবহার করা হয়েছিল mq-deadline। সুতরাং এটি নতুন blk-mqকোডটি ব্যবহার করছিল )।

পরীক্ষা এবং ফলাফল

$ sudo perf trace -s \
       perf stat \
       dd if=/dev/urandom of=test.out bs=1M oflag=direct count=3000

3000+0 records in
3000+0 records out
3145728000 bytes (3.1 GB, 2.9 GiB) copied, 31.397 s, 100 MB/s

 Performance counter stats for 'dd if=/dev/urandom of=test.out bs=1M oflag=direct count=3000':

         18,014.26 msec task-clock                #    0.574 CPUs utilized          
             3,199      context-switches          #    0.178 K/sec                  
                 4      cpu-migrations            #    0.000 K/sec                  
               328      page-faults               #    0.018 K/sec                  
    45,232,163,658      cycles                    #    2.511 GHz                    
    74,538,278,379      instructions              #    1.65  insn per cycle         
     4,372,725,344      branches                  #  242.737 M/sec                  
         4,650,429      branch-misses             #    0.11% of all branches        

      31.398466725 seconds time elapsed

       0.006966000 seconds user
      17.910332000 seconds sys

 Summary of events:
...
 dd (4620), 12156 events, 12.0%

   syscall            calls    total       min       avg       max      stddev
                               (msec)    (msec)    (msec)    (msec)        (%)
   --------------- -------- --------- --------- --------- ---------     ------
   read                3007 17624.985     0.002     5.861    12.345      0.21%
   write               3003 13722.837     0.004     4.570   179.928      2.63%
   openat                12     0.371     0.002     0.031     0.267     70.36%
...

iowaitএর waকলাম থেকে চিত্রটি পড়েছি vmstat। ioকলামটি ( bo= 1K ব্লক আউটপুট) দেখে পরীক্ষাটি কখন চলছে তা আপনি বলতে পারেন ।

$ vmstat 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 0  0      0 5126892 176512 1486060   0   0  1788  4072  321  414  4  4 83  9  0
 1  0      0 5126632 176520 1485988   0   0     0     7  212  405  0  1 99  0  0
 0  0      0 5126884 176520 1485988   0   0     0     0  130  283  0  0 99  0  0
 0  0      0 5126948 176520 1485908   0   0     0     1  157  325  0  0 99  0  0
 0  0      0 5126412 176520 1486412   0   0   115     0  141  284  0  0 99  0  0
 0  2      0 5115724 176548 1487056   0   0     0  6019 18737 10733  3  6 89  2  0
 1  0      0 5115708 176580 1487104   0   0     3 91840 1276  990  0 13 77  9  0
 1  0      0 5115204 176600 1487128   0   0     2 91382 1382 1014  0 14 81  4  0
 1  0      0 5115268 176636 1487084   0   0     4 88281 1257  901  0 14 83  3  0
 0  1      0 5113504 177028 1487764   0   0    77 92596 1374 1111  0 15 83  2  0
 1  0      0 5114008 177036 1487768   0   0     0 113282 1460 1060  0 16 81  2  0
 1  0      0 5113472 177044 1487792   0   0     0 110821 1489 1118  0 16 74 10  0
 0  0      0 5123852 177068 1487896   0   0     0 20537  631  714  1  3 94  2  0
 0  0      0 5123852 177076 1487856   0   0     0    10  324  529  2  1 98  0  0
 2  0      0 5123852 177084 1487872   0   0     0    70  150  299  0  0 99  0  0

এটি যেখানে রাখে পরীক্ষার ফলাফল (কোনও ভিএম এর ভিতরে)

আমি 1 সিপিইউ দিয়ে ভিএম এর ভিতরে একই পরীক্ষার চেষ্টা করেছি, যা কার্নেলটি চালাচ্ছিল 5.0.9-301.fc30.x86_64এবং ব্যবহার করছে mq-deadline(এবং এ কারণে ব্লক-এমকিউ)। এই পরীক্ষায়, এটি কীভাবে আমি এটি প্রত্যাশা করেছিলাম তা কাজ করেছিল।

$ sudo perf trace -s \
       perf stat \
       dd if=/dev/urandom of=test.out bs=1M oflag=direct count=3000
[sudo] password for alan-sysop:
3000+0 records in
3000+0 records out
3145728000 bytes (3.1 GB, 2.9 GiB) copied, 46.8071 s, 67.2 MB/s

 Performance counter stats for 'dd if=/dev/urandom of=test.out bs=1M oflag=direct count=3000':

         18,734.89 msec task-clock                #    0.400 CPUs utilized
            16,690      context-switches          #    0.891 K/sec
                 0      cpu-migrations            #    0.000 K/sec
               328      page-faults               #    0.018 K/sec
   <not supported>      cycles
   <not supported>      instructions
   <not supported>      branches
   <not supported>      branch-misses

      46.820355993 seconds time elapsed

       0.011840000 seconds user
      18.531449000 seconds sys


 Summary of events:
...
 dd (1492), 12156 events, 38.4%

   syscall            calls    total       min       avg       max      stddev
                               (msec)    (msec)    (msec)    (msec)        (%)
   --------------- -------- --------- --------- --------- ---------     ------
   write               3003 28269.070     0.019     9.414  5764.657     22.39%
   read                3007 18371.469     0.013     6.110    14.848      0.53%
   execve                 6    10.399     0.012     1.733    10.328     99.18%
...

এর আউটপুট vmstat 5:

$ vmstat 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----                                                                     
 r  b  swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st                                                                     
 0  0     0 726176  52128 498508    0    0  2040   231  236  731  7  5 77 11  0                                                                     
 0  0     0 726176  52136 498508    0    0     0    10   25   46  0  0 99  1  0                                                                     
 0  0     0 726208  52136 498508    0    0     0     0   29   56  0  0 100  0  0                                                                    
 0  1     0 702280  55944 511780    0    0  2260 13109 4399 9049  3 17 55 25  0                                                                     
 0  1     0 701776  56040 511960    0    0    18 129582 1406 1458 0 73  0 27  0                                                                    
 0  2     0 701524  56156 512168    0    0    22 87060  960  991  0 50  0 50  0                                                                     
 3  1     0 701524  56228 512328    0    0    14 118170 1301 1322 0 68  0 32  0                                                                    
 1  1     0 701272  56260 512392    0    0     6 86426  994  982  0 53  0 46  0                                                                     
 0  2     0 701020  56292 512456    0    0     6 56115  683  660  0 37  0 63  0                                                                     
 3  2     0 700540  56316 512504    0    0     5 33450  446  457  0 26  0 74  0                                                                     
 0  2     0 700860  56332 512536    0    0     3 16998  311  240  0 19  0 81  0                                                                     
 1  2     0 700668  56368 512616    0    0     7 32563  443  428  0 24  0 76  0                                                                     
 1  0     0 700668  56392 512648    0    0     3 20338  245  272  0 12  0 88  0                                                                   
 0  1     0 707096  56408 512920    0    0    54 20913  312  530  0 12 79  8  0                                                                     
 0  0     0 707064  56432 512920    0    0     0    49   39   64  0  0 45 55  0                                                                     
 0  0     0 707064  56432 512920    0    0     0     0   24   46  0  0 100  0  0                                                                    
 0  0     0 707064  56432 512920    0    0     0    80   28   47  0  0 100  0  0

আমি ভিএম-তে একটি সিপিইউ হট-এড করার চেষ্টা করেছি এবং আবারও পরীক্ষার চেষ্টা করেছি। ফলাফলগুলি পরিবর্তনশীল ছিল: কখনও কখনও এটি নিষ্ক্রিয় কলামে প্রায় 0% দেখায় এবং কখনও কখনও এটি প্রায় 50% অলস দেখায় (অর্থাত্ দুটি সিপিইউয়ের মধ্যে একটি)। 0% "অলস" এর ক্ষেত্রে, "আইওয়েট" খুব বেশি ছিল অর্থাৎ একাধিক সিপিইউ'র মূল্য। অর্থাৎ আমার প্রত্যাশা পয়েন্ট 2 সঠিক ছিল না। মাল্টি-সিপিইউ সিস্টেমে "আইওয়েট" এর এই আপাত সীমাবদ্ধতা আমি ভিক্ষাব্রতভাবে গ্রহণ করতে পারি । (যদিও আমি এটি বেশ বুঝতে পারি না someone কেউ যদি এটির সঠিক ব্যাখ্যা দিতে চায় তবে তা দুর্দান্ত। যাইহোক, "নিষ্ক্রিয়" উভয় ক্ষেত্রেই 50% এর উপরে ছিল না, সুতরাং এই পরীক্ষাগুলি এখনও "আইওয়েট" সম্পর্কে আমার প্রথম অনুমানের সাথে সামঞ্জস্যপূর্ণ ছিল।

আমি ভিএম বন্ধ করে 4 সিপিইউ দিয়ে শুরু করার চেষ্টা করেছি। একইভাবে, প্রায়শই আমি প্রায় 75% অলস ছিলাম, এবং কখনও কখনও আমার কাছে 50% অলস থাকে, তবে আমি 75% এর বেশি অলস দেখি না (অর্থাত্ চারটি সিপিইউয়ের মধ্যে তিনটির বেশি)।

যদিও 4 টি সিপিইউ সহ শারীরিক সিস্টেমে, আমি এখনও উপরে দেখানো হিসাবে 80% এর বেশি অলস ফলাফল পুনরুত্পাদন করতে পারি।

linux

— sourcejedi
সূত্র

আপনি আপনার দুটি প্রত্যাশা কিছুটা মন্তব্য করতে আপত্তি করতে চান? আপনি কী যুক্ত করতে পারবেন আসল মানটি আপনার প্রত্যাশার চেয়ে কম বা কম ছিল কিনা। আমি বুঝতে পারি এটি কাঁচা ডেটাতে রয়েছে, এটি কেবল আরও কিছুটা পাঠযোগ্য হবে। আপনি কেন 1 সিপিইউ (100%) আশা করেন সে সম্পর্কে আমি কিছুটা অস্পষ্ট। আপনার লিঙ্কগুলির একটি এবং আপনার উদ্ধৃত কার্নেল কোডের উপর ভিত্তি করে , একটি একক আইও ক্রিয়াকলাপ সমস্ত আইডিএল সময়কে আইওএআইএটি সময় (সমস্ত 4 কোরি - 400%) এ স্যুইচ করবে।

— ফিলিপ কাপলিং

ফিলিপকুলিং "আমি প্রত্যাশা করেছি যে আমি কমপক্ষে একটি সম্পূর্ণ সিপিইউ" নন-অলস "হিসাবে দেখব ... এটি ছিল না"। অলস সময়টি প্রত্যাশার চেয়ে বেশি ছিল, যা আমি আইওয়েটের সময়টি আমার প্রত্যাশার চেয়ে কম হওয়ার জন্য দোষ দিয়েছি। কার্নেল কোডটিতে, আমি মনে করি this_rq()->nr_iowaitযে io_schedule() কেবলমাত্র বর্তমান সিপিইউ ব্যবহার করে অপেক্ষা করা কর্মগুলি । আমি কি ভূল?

— সোর্সজেদি

আমি মোটেও নিশ্চিত নই, তবে তা যদি হয় তবে আমি অবাক হই। এই আশ্চর্যতা স্টিফেন কিটের উত্তরের সাথে মিলিত হয়েছে যেখানে তিনি বলেছেন " iowaitসাধারণভাবে I / O এর জন্য অপেক্ষা করা সময় মাপার চেষ্টা করে। এটি কোনও নির্দিষ্ট সিপিইউ দ্বারা অনুসরণ করা যায় না, এটি হতেও পারে না" । আমাকে চাপ দিন আমি এ সম্পর্কে নিশ্চিত নই, কেবল আশ্চর্যতা প্রকাশ করছি।

— ফিলিপ কুলিং

আপনি ফিলিপচুলিং চালিয়ে যাচ্ছেন atopবা atopsar -c 5আপনি প্রতি সিপিইউ ব্যবহারের পরিসংখ্যান দেখতে পাবেন। এগুলিতে আইওয়েট অন্তর্ভুক্ত রয়েছে এবং প্রতি-সিপিইউ আইওয়েট পরিসংখ্যানগুলি ভিন্ন, শূন্য-না-মানগুলি দেখায় :-)। অথবা sar -P ALL 1, যদি আপনি ব্যবহার না করেন atop। iowaitমাল্টি-সিপিইউ সিস্টেমগুলির জন্য এভাবেই মডেলটি প্রসারিত করা হয়েছে ... আমি কী অস্পষ্ট তা এই মডেলটি আসলে ব্যবহারযোগ্য কিনা, বা কেবলমাত্র একটি সিপিইউ থাকা অবস্থায় আইওয়েট কোডটি কাজ চালিয়ে যেতে দেয় কিনা তা এই কিনা? অনলাইন, তবে এটি অন্যথায় বিশ্বাসযোগ্য নয়।

— সোর্সজেডি

সামগ্রী বিজ্ঞপ্তি : এই পোস্টে বিভিন্ন লিনাক্স আলোচনা এবং কোডের লিঙ্ক অন্তর্ভুক্ত রয়েছে। কিছু লিঙ্কযুক্ত সামগ্রী স্ট্যাক এক্সচেঞ্জ বা লিনাক্সের জন্য বর্তমান আচরণবিধির সাথে মেলে না । বেশিরভাগ ক্ষেত্রে তারা "কোডটি অপমান করে [তবে ব্যক্তিটি নয়]"। তবে কিছু ভাষা ব্যবহৃত হয়, এটি কেবল পুনরাবৃত্তি করা উচিত নয়। আমি আপনাকে অনুরোধ করছি এ জাতীয় ভাষার অনুকরণ, পোড়ামাটি বা বিতর্ক এড়ানোর জন্য।

পুনরায়: আইওয়ায়েট বনাম নিষ্ক্রিয় অ্যাকাউন্টিং "বেমানান" - আইওয়েট খুব কম

05/07/2019 12:38 এ, পিটার জিজলস্ট্রা লিখেছেন:

শুক্রবার, জুলাই 05, 2019 এ 12:25:46 পিএম +0100 এ, অ্যালান জেনকিনস লিখেছেন:

আমার সিপিইউ "আইওয়েট" সময়টি ভুলভাবে প্রতিবেদন করা হয়েছে। কেন এমন হতে পারে জানেন?

কারণ আইওয়েট হ'ল একটি যাদু র্যান্ডম সংখ্যা যার কোনও বুদ্ধিমান অর্থ নেই। ব্যক্তিগতভাবে আমি শুধু পুরো জিনিস মুছে ফেলতে ছাড়া পেশ করবো ABI- র : /

এছাড়াও এনআর_আইওয়েটের নিকট মন্তব্য দেখুন ()

ধন্যবাদ। আমি [বর্তমান ডকুমেন্টেশনে উল্লিখিত সমস্যাগুলি] বিভিন্ন সমস্যা হিসাবে বিবেচনা করি তবে আপনার অর্থ আমার সমস্যাটি "সমাধান" করার জন্য খুব বেশি চাহিদা (বা পয়েন্ট) নেই।

আমি আমার সমস্যা খুঁজে পেয়েছি। পাঁচ বছর আগে এটি ইতিমধ্যে লক্ষ্য করা গেছে, এবং এটি সংশোধন করা তুচ্ছ হবে না।

"আইওয়েট" সময়টি ফাংশনটির মাধ্যমে আপডেট হয় account_idle_time():

/*
 * Account for idle time.
 * @cputime: the CPU time spent in idle wait
 */
void account_idle_time(u64 cputime)
{
    u64 *cpustat = kcpustat_this_cpu->cpustat;
    struct rq *rq = this_rq();

    if (atomic_read(&rq->nr_iowait) > 0)
        cpustat[CPUTIME_IOWAIT] += cputime;
    else
        cpustat[CPUTIME_IDLE] += cputime;
}

এটি যেমনটি প্রত্যাশা করা হয়েছিল তেমনভাবে কাজ করে, আপনি যদি traditionalতিহ্যবাহী টাইমার বিঘ্নিত ("টিক") এর সাথে "স্যাম্পলিং" করে সিপিইউ সময়টি প্রায় অনুমান করছেন । তবে, শক্তি বাঁচাতে নিষ্ক্রিয় সময়ের মধ্যে টিকটি বন্ধ করা থাকলে এটি কাজ করতে পারে না - NO_HZ_IDLE। পারফরম্যান্সের কারণে যদি আপনি টিকটি বন্ধ করার অনুমতি দেন তবে এটি ব্যর্থও হতে পারে NO_HZ_FULL- কারণ এটি শুরু করা দরকার VIRT_CPU_ACCOUNTING। বেশিরভাগ লিনাক্স কার্নেলগুলি পাওয়ার-সঞ্চয় বৈশিষ্ট্যটি ব্যবহার করে। কিছু এম্বেড থাকা সিস্টেম দুটি বৈশিষ্ট্যই ব্যবহার করে না। এখানে আমার ব্যাখ্যা:

আইও সম্পূর্ণ হয়ে গেলে, ডিভাইস একটি বাধা প্রেরণ করে । কার্নেল বিঘ্নিত হ্যান্ডলার ব্যবহার করে প্রক্রিয়াটি জাগ্রত করে try_to_wake_up()। এটি nr_iowaitকাউন্টার থেকে একটিকে বিয়োগ করে :

if (p->in_iowait) {
    delayacct_blkio_end(p);
    atomic_dec(&task_rq(p)->nr_iowait);
}

প্রক্রিয়াটি যদি অলস সিপিইউতে জেগে থাকে, তবে সেই সিপিইউ কল করে account_idle_time()। কোন কনফিগারেশন প্রযোজ্য তার উপর নির্ভর করে এটিকে বলা হয় কোথা tick_nohz_account_idle_ticks()থেকে __tick_nohz_idle_restart_tick(), বা কোথা vtime_task_switch()থেকে finish_task_switch()।

এই সময়ের মধ্যে, ->nr_iowaitইতিমধ্যে হ্রাস করা হয়েছে। যদি এটি শূন্যে কমে যায় তবে কোনও আইওয়েট সময় রেকর্ড করা হবে না।

এই প্রভাবটি পৃথক হতে পারে: এটি নির্ভর করে কোন সিপিইউ প্রক্রিয়াটি জেগেছে। যদি প্রক্রিয়াটি একই সিপিইউতে জেগে থাকে যা আইও সমাপ্তি বাধা পায়, অলস সময়টি আগে ->nr_iowaitহ্রাস করা যেতে পারে । আমার ক্ষেত্রে, আমি সিপিইউ 0 টি দেখেছি, এবং আহকি বাধা হ্যান্ডলগুলি পেয়েছি watch cat /proc/interrupts।

আমি এটি একটি সাধারণ ক্রমযুক্ত পড়ার সাথে পরীক্ষা করেছি:

dd if=largefile iflag=direct bs=1M of=/dev/null

আমি যদি কমান্ডটি সিপিইউ 0 তে ব্যবহার করে পিন করি তবে আমি taskset -c 0 ...আইওয়েটের জন্য "সঠিক" মান দেখতে পাচ্ছি। যদি আমি এটি আলাদা সিপিইউতে পিন করি তবে আমি অনেক কম মান দেখতে পাচ্ছি। যদি আমি কমান্ডটি সাধারণত চালিত করি তবে এটি শিডিউল আচরণের উপর নির্ভর করে পরিবর্তিত হয়, যা কার্নেল সংস্করণগুলির মধ্যে পরিবর্তিত হয়েছে। সাম্প্রতিক কার্নেলগুলিতে (৪.১17, ৫.১, ৫.২-আরসি 5-ইশ) কমান্ডটি সিপিইউ 0-তে প্রায় 1/4 সময় ব্যয় করে বলে মনে হচ্ছে, কারণ "আইওয়েট" সময়টি সেই ভগ্নাংশে হ্রাস পেয়েছে।

(ব্যাখ্যা করা হয়নি: আমার ভার্চুয়াল মেশিনে কেন এই পরীক্ষা চালানো এখন প্রতিটি (বা যে কোনও) সিপিইউর জন্য "সঠিক" আইওয়েটকেই পুনরুত্পাদন করে বলে মনে হচ্ছে this আমি এতে জড়িত থাকতে পারে সন্দেহ করি IRQ_TIME_ACCOUNTING, যদিও এই বৈশিষ্ট্যটি ভিএম এর বাইরেও আমার পরীক্ষায় ব্যবহৃত হচ্ছে)।

আমি এও নিশ্চিত করেছিলাম না যে দমন করার কারণে কেন NO_HZ_IDLEপ্রতিটি সিপিইউয়ের জন্য 4.17+ বা "সঠিক" আইওয়েট দেওয়া হয়, তবে 4.16 বা 4.15 এ নয়।

আমার ভার্চুয়াল মেশিনে এই পরীক্ষা চালিয়ে যাওয়া প্রতিটি (বা যে কোনও) সিপিইউয়ের জন্য "সঠিক" আইওয়েটের পুনরুত্পাদন বলে মনে হয়। এই কারণে হয় IRQ_TIME_ACCOUNTING। এটি ভিএম এর বাইরের পরীক্ষাগুলিতেও ব্যবহৃত হয়, তবে ভিএম এর ভিতরে পরীক্ষা করার সময় আমি আরও বাধা পাই get বিশেষত, ভার্চুয়াল সিপিইউতে প্রতি সেকেন্ডে 1000-এরও বেশি "ফাংশন কল ইন্টারপ্টস" রয়েছে যা "ডিডি" চলছে।

সুতরাং আপনি আমার ব্যাখ্যা বিশদ উপর খুব বেশি নির্ভর করবেন না :-)

এখানে "আইওয়েট" সম্পর্কে কিছু পটভূমি রয়েছে: একটি সিপিইউ কীভাবে জানতে পারে যে সেখানে আইও মুলতুবি রয়েছে? উত্তর এখানে পাল্টা স্বজ্ঞাত ধারণাটি উদ্ধৃত করে, যে ক্রমবর্ধমান আইওয়েট "কিছু পরিস্থিতিতে কমে যেতে পারে"। আমি ভাবছি যে আমার সাধারণ পরীক্ষাটি যদি এইরকম একটি অননুমোদিত অবস্থাকে ট্রিগার করতে পারে?

হ্যাঁ.

আমি প্রথম যখন এটি সন্ধান করেছি, তখন আমি "হিচাপ্পস" এর আলাপ পেলাম। এছাড়াও, সংঘটিত "আইওয়ায়েট" সময়টি অ-একঘেয়েমি করে দেখিয়ে সমস্যার চিত্রণ করা হয়েছিল। এটি কখনও কখনও পিছন দিকে লাফিয়ে যায় (হ্রাস)। এটি উপরের পরীক্ষার মতো সোজা ছিল না।

যাইহোক, তারা তদন্ত করার সময় তারা একই মৌলিক সমস্যা খুঁজে পেয়েছিল। যথাক্রমে পিটার জিজলস্ট্রা এবং হিদেটোশি সেটো একটি সমাধান প্রস্তাব এবং প্রোটোটাইপ করেছিলেন। সমস্যাটি কভার বার্তায় ব্যাখ্যা করা হয়েছে:

[আরএফসি প্যাচ 0/8] আইওয়েট অ্যাকাউন্টিং পুনরায় কাজ করুন (2014-07-07)

আমি এর বাইরে অগ্রগতির কোনও প্রমাণ পাইনি। বিশদগুলির একটির উপর একটি মুক্ত প্রশ্ন ছিল। এছাড়াও, সম্পূর্ণ সিরিজটি পাওয়ারপিসি, এস390 এবং আইএ 64 সিপিইউ আর্কিটেকচারের জন্য নির্দিষ্ট কোডটি স্পর্শ করেছে। সুতরাং আমি বলছি এটি ঠিক করা তুচ্ছ নয়।

— sourcejedi
সূত্র

আপনি নিশ্চিত বা অস্বীকার করতে পারবেন (ভিএমস্ট্যাট ব্যবহার করে): কার্নেল 4.15 সক্ষম বা অক্ষম আইডলগুলি নির্বিশেষে আপনি যা প্রত্যাশা করেন তা করে; কার্নেল 4.16 আপনি নির্বিশেষে যা প্রত্যাশা করেন তা করে না। ভিএমস্ট্যাট ব্যবহার করার মতো মনে হয় /proc/stat, তবে আমি ব্যবহার করি /sys/devices/system/cpu/cpu*/cpuidle/state*/usageএবং আমার জ্ঞানের সেরাটি সর্বদা সঠিক ছিল (+ - কয়েক%)। আমি পুরানো কার্নেলগুলিতে আমার সরঞ্জামগুলি ব্যবহার করতে পারি না কারণ কিছু নতুন তথ্য নেই। নোট করুন যে আমি টেস্ট 1 এবং টেস্ট 3 একই ফলাফল দেবে বলে আশা করি, কারণ টিকটি কখনই নিষ্ক্রিয় অবস্থায় থাকে না 0.

— ডগ স্মিথিস

আমি /sys/devices/system/cpu/cpu*/cpuidle/state*/timeউপরে লিখতে চেয়েছিলাম । আমি কেবল কার্নেলটি দ্বিখণ্ডিত করার কথা ভাবতে পারি, একবার একবার কার্নেল 4.15 এবং 4.16 এর মধ্যে, তারপরে আবার 4.16 এবং 4.17 এর মধ্যে। দ্বিতীয় দ্বিধাজ্ঞান প্রথম থেকে প্রাপ্ত জ্ঞানের সাথে দ্রুত যেতে পারে। আমার এখনই এটি করার সময় নেই, সম্ভবত কয়েক দিনের মধ্যে।

— ডগ স্মিটিজ

@ ডগস্মিথিজ আপনাকে ধন্যবাদ! আপনার পরীক্ষাগুলি আমার মূল পরীক্ষাগুলির পাশাপাশি কাজ করে। আমার ফলাফল 4.15.0-1.fc28এবং 4.16.0-300.fc28আপনার সাথে একমত।

— সোর্সজেডি

ঠিক আছে আমি মনে করি আমি একটি লিনাক্স-বিকেল তালিকা জবাবের জন্য প্রস্তুত। আশা করি কারও কারও কাছে অন্তর্দৃষ্টি থাকবে এবং আমরা কার্নেলের দ্বিখণ্ডন এড়াতে পারি।

— ডগ স্মিটিজ

পুনঃটুইট প্রথম দ্বিখণ্ডন (4.15-4.16) github.com/torvalds/linux/commit/806486c377e3 " সময়সূচি / ফর্সা: প্রিভিসিপি নিষ্ক্রিয় থাকলে স্থানান্তর করবেন না"। সুতরাং আমি taskset -c 0v4.15 তে পরীক্ষা করেছি ... ddকমান্ডটি চালানো taskset -c 2"ডান" আইওয়েট দেয়। অন্য কোনও সিপিইউতে পিন করা "ভুল" আইওয়েট দেয়। Cpu2 হল যেখানে ddআমি ব্যবহার না করলে শেষ হয় taskset। (আমি atopপ্রতি সিপিইউ আইওয়েট সময় দেখতাম)। আমি বর্তমান দ্বিধাদ্বন্দ্বের দিকে একবার নজর রাখছি, বর্তমান আচরণটি ব্যাখ্যা করার জন্য। সুযোগটিতে দ্বিতীয় পরিবর্তন সম্পর্কে এই সম্পর্কে কিছু মন্তব্য থাকতে পারে।

— সোর্সজেডি

সিস্টেম "আইওয়েট" সম্পর্কে আমার প্রাথমিক ধারণাটি ধারণ করে না

আসল প্রশ্ন

"আইওয়ায়েট" এর পটভূমি তথ্য

পরিবেশ

পরীক্ষা এবং ফলাফল

এটি যেখানে রাখে পরীক্ষার ফলাফল (কোনও ভিএম এর ভিতরে)