Setiap tahun, Google menyelenggarakan acara Google Summer of Code, di mana proyek OpenSource terkemuka menemukan pengembang baru yang berbakat di kalangan siswa. Pada tahun 2019, proyek CRIU kami tidak hanya berhasil melewati babak kualifikasi, tetapi juga untuk menarik beberapa pengembang muda sekaligus. Tentang mengapa semua ini, dan bagaimana pekerjaan pada CRUI berlangsung dalam kerangka GSoC - baca di bawah kucing.
Kami di Virtuozzo memiliki proyek kecil namun sudah cukup populer yang disebut CRIU. Ini adalah utilitas sistem yang agak rumit dan satu set tambalan kernel (kebanyakan dari mereka, sudah, telah diterima ke pohon kernel utama), yang dengannya Anda dapat melakukan hal-hal seperti, misalnya migrasi langsung kontainer atau memperbarui kernel tanpa memulai ulang aplikasi.
Kami memulai proyek ini kembali pada tahun 2011. Dan terlepas dari kenyataan bahwa utilitas tersebut pada awalnya menimbulkan banyak pertanyaan, dan beberapa menganggap implementasinya mustahil, CRIU secara bertahap berubah menjadi alat yang matang. Hingga saat ini, lebih dari satu setengah ratus kontributor dari beberapa lusin perusahaan, termasuk raksasa seperti Google dan IBM, telah berhasil berpartisipasi di dalamnya. Meskipun demikian, pencarian untuk anggota baru terus berlanjut, dan tahun ini kami akhirnya mencapai Google Summer of Code (GSoC).
GSoC adalah acara tahunan yang disponsori Google yang tujuannya adalah untuk menarik siswa ke berbagai proyek sumber terbuka. Di satu sisi, tim dari proyek terbuka berusaha untuk berpartisipasi dalam acara tersebut, dan di sisi lain, siswa yang ingin berkontribusi pada pengembangan masyarakat dan membuktikan profesionalisme mereka pada proyek nyata.
Untuk masuk ke tim GSoC, Anda perlu mengirimkan aplikasi yang menentukan deskripsi proyek, beberapa topik yang dapat dikerjakan siswa dan daftar yang disebut "mentor" - peserta aktif dalam proyek yang akan membantu siswa dalam pekerjaannya yang sulit. Siswa diminta untuk memilih satu proyek atau lebih dan mengirimkan resume mereka ke mentor.
Di tengah tahun sekolah, Google mempertimbangkan aplikasi tim dan memilih proyek yang akan berpartisipasi, dan lebih dekat dengan liburan musim panas, tim memilih siswa yang siap bekerja, setelah itu Google melakukan pemfilteran terakhir dan mendistribusikan siswa sesuai dengan tim. Di musim panas, pekerjaan dimulai, yang berlangsung tiga bulan. Sekali setiap 30 hari, siswa menyerahkan laporan sementara, dan mentor mereka mengevaluasi hasilnya dan membuat rekomendasi untuk kelanjutan (atau pemutusan) pekerjaan.
Optimalisasi memori dan implementasi log biner
Saya akui bahwa pada 2019 bukanlah upaya pertama kami untuk memasuki GSoC. Hingga saat ini, kami belum dapat melewati tahap pemilihan proyek dari Google. Tetapi kami tidak menyerah (secara umum, tidak sulit untuk mengirimkan aplikasi), dan akhirnya, semuanya berjalan baik - Google mengakui pengembangan proyek kami sebagai hal yang penting dan merilis CRUI di GSoC.
Kami memiliki banyak topik untuk siswa, satu lagi yang indah dan lebih kompleks. Kejutan yang menyenangkan adalah kenyataan bahwa untuk masing-masing dari mereka di komunitas ada pemain. Ada orang yang tahu masalah-masalah yang disuarakan dan siap untuk bekerja sebagai mentor. Pada tahap pengarsipan siswa, kami menerima seluruh "kompetisi" - 2 siswa mendaftar untuk masing-masing topik dan hampir semua memiliki data input yang bagus. Seleksi akhir memungkinkan kami untuk mendapatkan dua siswa yang mengambil topik optimisasi kode pelestarian memori dari proses yang sedang berlangsung, serta penerapan log biner.
Karena CRIU adalah sistem migrasi aplikasi langsung, ia memiliki mode operasi ketika memori yang digunakan proses dibaca dan ditulis ke file gambar secara paralel dengan pelaksanaan proses itu sendiri. Kami menyebut ini "operasi jantung yang hidup" dari proses tersebut, karena proses ini terus bekerja tanpa henti. Sebelum putaran GSoC, semua memori ditarik ke dalam pipa menggunakan panggilan sistem vmsplice, yang membuat suara pada satu waktu, dan kemudian proses terus dijalankan, dan CRIU perlahan-lahan membuang memori ini ke file (atau ke saluran jaringan jika itu merupakan migrasi langsung). Pada prinsipnya, ini adalah pendekatan yang berfungsi, tetapi masalahnya adalah bahwa memori yang terletak di pipa secara efektif terkunci (mlock) dan kernel tidak dapat membongkar ke disk (swap-out) jika perlu.
Dari sudut pandang arsitektur, kami ingin mengganti pipa untuk menyalin memori dalam porsi kecil dengan memanggil process_vm_readv. Inovasi ini muncul di kernel Linux belum lama ini (omong-omong, panggilan ini memiliki saudara kembar yang disebut process_vm_writev). Tetapi pada saat yang sama memungkinkan Anda untuk sangat memfasilitasi dan mempercepat, misalnya, pekerjaan utilitas strace dan debuggers, yang dapat menyodok memori proses untuk menyelesaikan beberapa tugas lainnya.
Bekerja pada pengoptimalan menjadi rumit oleh fakta bahwa kode untuk bekerja dengan memori proses adalah salah satu yang utama dalam utilitas, dan karena itu harus benar-benar dapat diandalkan. Kesalahan apa pun dalam menyimpan halaman dapat menyebabkan proses menerima keadaan objek internal yang tidak konsisten (tentang CRIU mana, tentu saja, tidak "tahu" apa pun) dan setelah pemulihan, ia akan jatuh tanpa diagnostik yang jelas.
Kesulitan kedua dari pengembangan ini adalah bahwa bekerja dengan memori terlibat di hampir semua fitur CRIU. Ini adalah prosedur pengembalian-pos pemeriksaan yang biasa, ini adalah berbagai versi yang dioptimalkan, misalnya pra-dump atau pengembalian malas. Suatu saat selama minggu pelaporan berikutnya, kami bahkan berencana untuk “memberhentikan” siswa dari proyek, tetapi, untungnya, kami tidak melakukan ini dan sekarang kami memiliki optimasi yang telah lama dinanti di cabang devel kami.
Tugas kedua dalam kerangka GSoC 2019 adalah pengembangan dan implementasi yang disebut log biner. Begini masalahnya: ketika CRIU bekerja, utilitas menulis pesan tentang kerjanya ke file (atau ke layar, tetapi masih lebih baik ke file). Pentingnya posting ini sangat besar! Jika prosedur pencadangan atau pemulihan untuk beberapa alasan tidak berakhir dengan sukses, maka satu-satunya cara untuk memahami alasannya adalah dengan menganalisis setiap langkah sedetail mungkin, dan untuk ini Anda memerlukan informasi tentang utilitas. Idealnya, proses memerlukan log dan file gambar paling detail, jika ada. Dalam praktiknya, persyaratan seperti itu sulit dipenuhi.
Untuk mendapatkan log yang paling rinci, CRIU menyediakan mode yang sesuai, dan sebagian besar pengguna (dan mungkin bahkan semua) selalu mengaktifkannya. Tetapi jumlah informasi yang dihasilkan criu dalam proses ini sangat besar sehingga pencatatan itu sendiri mulai mempengaruhi kecepatan sistem. Sebuah penelitian kecil telah menunjukkan bahwa kita menghabiskan 90% waktu kita untuk login pada operasi pemformatan output - yaitu, pada%% d yang sama,% 08s,% .2f, dan pengubah lain dari keluarga fungsi printf. Mematikan log mengurangi waktu menyimpan dan memulihkan proses dari 10 hingga 30 persen, tergantung pada ukuran proses itu sendiri.
Untuk mematikan penggunaan sejumlah sumber daya sistem untuk logging, tetapi membiarkan log se informatif mungkin, kami memutuskan untuk menyingkirkan pemformatan dan menyimpan data biner ke file log. Bagaimanapun, Anda dapat memformatnya nanti, jika perlu. Siswa kedua mengatasi tugas ini, yang tambalannya juga telah diterima ke cabang pengembangan.
Dan tidak hanya di GSoC
Ngomong-ngomong, fakta menarik lain dari berpartisipasi dalam GSoC adalah bahwa siswa ketiga datang kepada kami yang menyatakan keinginan untuk menyelesaikan masalah anonimisasi. Lagi pula, sering kali tidak mungkin untuk mendapatkan file gambar karena fakta bahwa mereka mengandung informasi rahasia yang tidak ingin dibagikan oleh pengguna secara adil kepada siapa pun - isi memori, file yang proses kerjanya, isi antrian dalam koneksi jaringan, dan sebagainya. Untuk mengatasi masalah ini, kami mengirimkan fitur yang disebut "anonimisasi gambar" dalam aplikasi, tetapi Google tidak menerimanya.
Namun demikian, topik tersebut tidak kehilangan relevansinya, dan siswa yang ingin menanganinya dalam kerangka kerja GSoC, pada akhirnya, memutuskan untuk mengerjakan masalah secara mandiri, di luar acara Google.
Kesimpulan
Itu, tentu saja, pengalaman positif berpartisipasi dalam GSoC. Alat CRIU kami, yang sangat kami cintai dan hargai, telah menerima beberapa impuls yang lebih kuat untuk pengembangan, itu telah menjadi lebih dewasa dan nyaman. Jadi bagi siapa ini mungkin bermanfaat, gunakan dengan senang hati!
Di sisi lain, kami yakin bahwa masalah partisipasi dalam acara seperti itu adalah masalah ketekunan dan kepercayaan diri dalam proyek kami. Jika Anda membutuhkan pengembang, jangan sampai bosan mengirimkan aplikasi dan merumuskan topik baru yang menarik. Anda dapat menemukan kontributor yang sama sekali tidak terduga dari negara lain atau bahkan dari perusahaan lain.