операція зчитування з двома взаємозамінними процесами та контекстним комутатором

P1 і P2 - це обидва процеси, відмінні один від одного. це операція читання, виконана на жорсткому диску:

Наведене вище є схемою інстукції читання в Linux. Чи правда, що краще уникати використання контекстного комутатора для покращення загальної якості?

(a) вірно, оскільки це дозволяє уникнути заміни в TLB.

(б) правда.

(в) неправильно.

(г) неправильно, неможливо уникнути виконання контекстного перемикання

Чому відповідь просто (с)? Я думав, що студент не може бути правильним, оскільки уникнення переключення контексту не покращує загальну якість, оскільки контекстна комутація використовується для кращої якості.

Я думав, що це повинно бути (г) бо, коли ми переходимо від Р1 до Р2, нам потрібен контекстний перемикач, щоб перейти від одного процесу до іншого.

Хтось може пояснити?

Гаразд, здається, що слід вибирати (c) over (d) просто тому, що (d) не відповідає дійсності.

Коли через деякий час P1 переходить у етап читання, ми говоримо про IO, тому процесор зайнятий. Спершу він повинен обробити запит вводу-виводу і дійти до цих даних, тому, хоча він робить саме це, планувальник запускає інший процес, щоб ми не втрачали час - це, однак, не має нічого спільного з контекстним комутатором.

Це я думаю. Це здається логічним?

Можна було б уникнути одного контекстного перемикача (перемикання з P2 на P1), не плануючи P2 для запуску, дочекавшись завершення роботи диска. Імовірно, якщо ви це зробили, тоді P1 відновить виконання трохи раніше, із теплішим TLB.

Ви не можете уникнути всієї комутації контексту, оскільки системний виклик включає контекстний перемикач (користувач на ядро), як і відновлення P1 після переривання завершення з пристрою. Але ви можете уникнути двох комутаторів контексту користувача (хоча лише один з комутаторів впливає на час P1).

Отже, якщо вашим єдиним вимірюванням продуктивності є те, наскільки швидко P1 виконується, ви можете витягти трохи більше, виділивши цей процесор P1 і не дозволяючи запускати будь-які інші процеси. Але ми знаємо, що активність диска повільна в порівнянні з переключенням контексту, і питання полягає в загальній продуктивності, а не лише в P1. Тому має сенс запланувати P2 під час очікування, навіть якщо він пізніше запустить відновлення P1.