Mengapa CPU menghabiskan waktu di IO (wa)?

Saya tahu wa(dalam top) mengukur waktu CPU menunggu I / O. Banyak artikel mengatakan itu.

Tapi saya bingung itu, berdasarkan 2 poin pengetahuan:

jika suatu proses menggunakan panggilan sistem untuk membaca disk, proses tersebut diblokir.
Jika suatu proses diblokir, itu tidak dapat dijadwalkan berjalan pada CPU.

Baik?

Sepertinya tidak ada waktu untuk CPU menunggu pada I / O ... Apa yang terjadi?

Jika merekomendasikan beberapa buku atau artikel untuk saya baca lebih lanjut, jauh lebih baik.

linux central-processing-unit io linux-kernel

— HUA Di
sumber

Saya masuk dan menulis jawaban yang tepat. Maaf saya tidak ada di sana ketika Anda membutuhkan saya ;-)

— Alec Teal

Jawaban:

Status siaga CPU dibagi dalam dua status "sub" yang berbeda: iowaitdan idle.

Jika CPU idle, kernel kemudian menentukan apakah ada setidaknya satu I / O saat ini sedang dalam proses untuk disk lokal atau disk yang dipasang dari jarak jauh (NFS) yang telah diinisiasi dari CPU tersebut. Jika ada, maka CPU dalam keadaan iowait. Jika tidak ada I / O dalam proses yang dimulai dari CPU itu, CPU dalam idlekeadaan.

Jadi, iowaitadalah persentase waktu CPU idle DAN ada setidaknya satu I / O dalam proses yang dimulai dari CPU itu.

The iowaitkontra menyatakan bahwa sistem dapat menangani pekerjaan lebih komputasi. Hanya karena CPU dalam iowaitkeadaan tidak berarti tidak dapat menjalankan utas atau proses lain pada CPU itu.

Jadi, iowaithanyalah bentuk waktu idle.

— kekacauan
sumber

Ini sebenarnya salah. Juga NFS - CPU bahkan tidak memiliki konsep itu. Ini pada dasarnya adalah waktu yang dihabiskan CPU untuk tidak dapat melakukan sesuatu yang lain karena berurusan dengan beberapa hal IO tingkat rendah - dalam arti mengakses sesuatu yang terhubung dengannya TIDAK memproses I / O yang biasanya membaca file dan yang lainnya. Sebagai contoh pada Raspberry Pi tidak ada DMA controller, jadi CPU tidak bisa "hei Motherboard baca saya banyak byte ini dimulai dari sini dari kartu dan menempatkan mereka di ram mulai di sini" itu harus melakukannya secara manual->

— Alec Teal

jadi itu menghabiskan BANYAK waktu DENGAN KONSTAN menunggu io seperti dalam untuk membaca kartu untuk menyelesaikan. Anda membuatnya terdengar seperti cache miss dapat diukur dengan "io tunggu" ini (yang tentu saja tidak dihitung), IO tunggu didefinisikan sebagai berikut: Waktu yang dihabiskan kernel di dalam perangkat I / O tingkat rendah rutin - mis. RPi, itu benar-benar harus melakukan prosedur membaca dari kartu dan CPU (menjadi DMA-kurang bodoh) harus menunggu data di bus IO. Dengan pengontrol DMA, ia berbicara kepada pengontrol dan mengatakan "beri tahu saya ketika Anda selesai" - membiarkannya melakukan hal-hal lain sementara pengontrol DMA melakukan perangkat IO

— Alec Teal

Gunakan dstat untuk melihat IOwaiting BTW, juga iowait dan waktu yang dihabiskan untuk melakukan hal-hal kernel tidak dapat diukur per-proses. Seperti mengatakan ada dua proses "menulis" menjadi "file", yang pertama selesai dengan cepat, FS memilih untuk menulis cache untuk alasan apa pun, yang kedua menyebabkan cache memerah, tidak adil untuk menghitung waktu yang jauh lebih lama untuk kembali dari menulis ke proses yang menyebabkan menulis. Sama dengan I / O tunggu, itulah sebabnya mereka tidak diukur per proses.

— Alec Teal

@AlecTeal: Tidak, itu benar dan komentar Anda salah. iowait menghitung waktu diblokir pada I / O, tidak melayani I / O. Jika Anda tidak ingin mengonfirmasi ini dengan membaca sumber kernel, cobalah percobaan: pasang sistem file jaringan, mulailah membaca file, dan kemudian firewall dari mesin jarak jauh. Waktu iowait masih akan tinggi meskipun prosesor benar-benar idle.

— David

Saya melakukan tes pada jawaban ini. dd if=/dev/sda of=/dev/nulluntuk membuat yang tinggi wa. Kemudian jalankan kode while-true, wabukan us. Kekacauan terima kasih.

— HUA Di

-2

Saya tidak 100% yakin saya mengerti pertanyaannya, tetapi ada beberapa ide.

Ada pertanyaan lain di sini yang menanyakan hal ini, dan memiliki beberapa jawaban yang bagus: Adakah yang bisa menjelaskan apa sebenarnya IOWait?

Ada posting yang bagus di sini: http://veithen.github.io/2013/11/18/iowait-linux.html

— Mike Fiedler
sumber

Mike, lebih disukai jawaban mencakup konten, bukan hanya tautan ke konten. Dengan menyediakan konten di sini, Anda memastikan bahwa jawaban Anda masih memiliki nilai ketika tautan itu hilang.

— EEAA

@ EEAA maka jawabannya perlu diedit, bukan triply downvoted? Atau bisa dipindahkan ke komentar. Masih berisi informasi yang bermanfaat. Downvotes berarti jenis info yang tidak berguna, juga dengan membuatnya hampir tidak terlihat? Saya tidak mengatakan bahwa Anda memang downvote, saya hanya ingin tahu tentang pendekatan yang dilakukan orang-orang di sini.

— Roland Pihlakas

@RandPihlakas Ini masalah motivasi. Downvote + komentar dalam situasi ini memberikan motivasi bagi pengguna untuk memperbaiki jawaban mereka. Saya dengan senang hati akan menghapus dv saya setelah jawabannya diperbaiki. Mengedit ini kontraproduktif, karena memungkinkan perilaku buruk. Kami telah memiliki beberapa pengguna selama bertahun-tahun yang hanya mengeposkan jawaban hanya tautan, meskipun diminta untuk tidak melakukannya. Jika pengguna tidak dapat repot-repot melakukan sedikit usaha dalam jawaban mereka, saya tidak akan membantu mereka dengan memperbaiki pekerjaan mereka.

— EEAA

@EEAA Terima kasih atas jawaban yang terperinci. Pendekatan Anda dapat dimengerti dan melalui komentar Anda, Anda memberikan dorongan motivasi untuk penulis jawaban juga. Sebaliknya, saya takut downvotes diam-diam sebagian besar tidak memberikan motivasi praktis karena mereka tidak jelas. Tapi saya agak tidak tepat - saya bertanya-tanya sebagian besar mengapa jawabannya turun begitu banyak sehingga menjadi abu-abu? Komentar Anda dengan satu atau dua downvote sudah cukup?

— Roland Pihlakas

@RolandPihlakas Orang-orang mengira jawabannya tidak berguna, jadi mereka menurunkan suara. Mereka diturunkan karena ini hari Selasa. Mereka turun karena turun salju di Minneapolis hari ini (sungguh, memang, dan seharusnya tidak selarut ini di musim semi). Siapa tahu.

— EEAA