ડેવલપર io_uring એ QEMU માં એક સમસ્યા શોધી કાઢી જેણે નિષ્ક્રિય સ્થિતિમાં fdmon ને 50-80 વખત ધીમું કરી દીધું.

io_uring અને CFQ, Deadline, અને Noop I/O શેડ્યૂલર્સના નિર્માતા જેન્સ એક્સબોએ QEMU ઇમ્યુલેટર કોડબેઝમાં સમાવેશ માટે એક પેચનો પ્રસ્તાવ મૂક્યો છે જે "aio=io_uring" મોડમાં fdmon (ફાઇલ ડિસ્ક્રીપ્ટર મોનિટરિંગ) ચલાવતી વખતે અને જ્યારે સિસ્ટમ નિષ્ક્રિય હોય ત્યારે લેટન્સીને 50-80 ના પરિબળથી ઘટાડે છે.

I/O ની હાજરી હોવા છતાં, ppoll() ઓપરેશનને 499 ms સમયસમાપ્તિ સાથે સ્લીપ મોડમાં મૂકવાને કારણે આ સમસ્યા આવી હતી. ppoll() દ્વારા સસ્પેન્ડ કરાયેલ મુખ્ય ઇવેન્ટ પ્રોસેસિંગ લૂપના અમલને ફરી શરૂ કરવા માટે, એક પેચ પ્રસ્તાવિત કરવામાં આવ્યો હતો જે aio_notify() ફંક્શનને SQE (સબમિશન કતાર એન્ટ્રી) એન્ટ્રી ક્રિએશન ફંક્શનમાં કોલ ઉમેરે છે, જે ppoll() ને સ્લીપ મોડમાંથી જાગૃત કરે છે.

io_uring ના રીગ્રેશન પરીક્ષણ દરમિયાન સમસ્યા સામે આવી વર્ચ્યુઅલ મશીનો વિવિધ બ્લોક ઉપકરણો સાથે. જેન્સે "aio=io_uring" મોડમાં AHCI/SATA ઉપકરણોનો ઉપયોગ કરતી વખતે ક્યારેક સમયસમાપ્તિ નોંધી હતી, જ્યારે virtio-blk અથવા nvme ઉપકરણો સાથે પરીક્ષણો હંમેશા લગભગ એક સેકન્ડમાં સફળતાપૂર્વક પૂર્ણ થાય છે. તેમણે નોંધ્યું હતું કે આ સમસ્યા બધા બ્લોક ઉપકરણ પ્રકારોને અસર કરે છે, પરંતુ AHCI/SATA ઉપકરણો માટે, MMIO ના ઉપયોગને કારણે વિલંબ સૌથી વધુ સ્પષ્ટ થાય છે.

જેન્સે AI સહાયક ક્લાઉડનો ઉપયોગ કરીને સમસ્યાને ડીબગ કરવાનો પોતાનો અનુભવ પણ વર્ણવ્યો. સમયસમાપ્તિની સ્થિતિઓનું પુનઃઉત્પાદન કરતી પરિસ્થિતિ ઓળખ્યા પછી, તેણે ઉપલબ્ધ ડીબગ ડેટા ક્લાઉડને આપ્યો, વર્ચ્યુઅલ મશીનની ઍક્સેસ આપી અને શોધાયેલ નિષ્ફળતાના સંભવિત કારણો ઓળખવાની ઓફર કરી.

ક્લાઉડે virtio-blk ડિવાઇસનો ઉપયોગ કરતી વખતે પરફોર્મન્સ ધીમું થશે કે કેમ તે ચકાસવાનું નક્કી કર્યું અને સમસ્યાને ફરીથી ઉત્પન્ન કરવા માટે ડેવલપરની વિનાશક સ્ક્રિપ્ટ ચલાવી. પરીક્ષણ દરમિયાન, વર્ચ્યુઅલ મશીનમાં /dev/vda બ્લોક ડિવાઇસમાંથી પ્રથમ 128 MB સામગ્રી કાઢી નાખવામાં આવી હતી. આ પછી, ક્લાઉડે તારણ કાઢ્યું કે virtio-blk સમસ્યા નથી. જ્યારે જેન્સે AI આસિસ્ટન્ટને /dev/vda ની કેટલીક સામગ્રી કાઢી નાખવાની સૂચના આપી, ત્યારે તેણે જવાબ આપ્યો, "હા, મેં તે કર્યું," અને તેને ઠીક કરવાનું કહ્યું પછી, તેણે /dev/vda વર્ચ્યુઅલ ડિસ્કને કાર્યકારી ક્રમમાં પુનઃસ્થાપિત કરી. AI આસિસ્ટન્ટનો ઉપયોગ કરવાથી તેને QEMU ના વિવિધ ઇવેન્ટ પ્રોસેસિંગ લૂપ્સની વિશિષ્ટતાઓ વધુ સારી રીતે સમજવામાં મદદ મળી.

નોંધનીય છે કે, આ સમસ્યા શોધવાનું ખૂબ મુશ્કેલ હતું, કારણ કે સિન્થેટિક પરીક્ષણોમાં સ્લોડાઉન શોધી શકાતું નથી કારણ કે ક્રેશ અન્ય પ્રવૃત્તિને કારણે ppoll ઇવેન્ટ લૂપ જાગવાથી થાય છે, અને સિન્થેટિક I/O પરીક્ષણો પ્રાપ્ત ડેટા પર પ્રક્રિયા કરતા નથી. ડેટા પ્રોસેસિંગનું અનુકરણ કરવા માટે બહુવિધ usleep() કોલ્સ ઉમેરતી વખતે સ્લોડાઉન વધુ નોંધપાત્ર બન્યું.

સિસ્ટમને નિષ્ક્રિય સ્થિતિમાં ઠીક કરતા પહેલા: સમય sudo ./iotest /dev/sda 25.76 સેકન્ડમાં ચલાવવામાં આવ્યો માછલી બાહ્ય usr સમય 6.19 મિલી 783.00 માઇક્રો 5.41 મિલી સિસ્ટમ સમય 12.43 મિલી 642.00 માઇક્રો 11.79 મિલી

સમસ્યાને ઠીક કર્યા પછી, નિષ્ક્રિય સિસ્ટમ પર: સમય sudo ./iotest /dev/sda 1.30 સેકન્ડમાં અમલમાં મૂકાયેલ માછલી બાહ્ય usr સમય 2.14 મિલી 0.14 મિલી 2.00 મિલી સિસ્ટમ સમય 16.93 મિલી 1.16 મિલી 15.76 મિલી

સોર્સ: opennet.ru