COS3721
Assignment 2 2026
Unique number:
Due Date: June 2026
QUESTION 01
a. How each approach schedules CPU-intensive and short interactive tasks
In the per-core run queue approach, each processor core has its own ready queue, so
tasks are placed on a specific core and that core selects tasks only from its own queue.
CPU-intensive tasks, such as video encoding, may continue running on the same core for
long periods, which can improve cache use because the process often reuses data already
stored close to that core. Short interactive tasks are also placed in one of the core queues,
but their response time may suffer if they are placed behind long CPU-intensive tasks on a
busy core.
In the shared run queue approach, all ready processes are kept in one global queue, and
any free processor core can take the next available task from that queue. CPU-intensive
tasks are selected from the same queue as interactive tasks, so the system can spread work
across all eight cores more easily. Short interactive tasks may get quicker attention because
an idle core can take them directly from the global queue instead of waiting for one specific
Terms of use
overloaded core to finish its work. The question in TL102 asks this in the context of an eight-
By making use of this document you agree to:
core server Use this document
that runs both CPU-intensive as a guide
and short for learning,
interactive comparison and reference purpose,
tasks.
Terms of use
Not to duplicate, reproduce and/or misrepresent the contents of this document as your own work,
By making use of this document you agree to:
Use this document
Fully accept the consequences
solely as a guide forshould you plagiarise
learning, or and
reference, misuse this document.
comparison purposes,
Ensure originality of your own work, and fully accept the consequences should you plagiarise or misuse this document.
Comply with all relevant standards, guidelines, regulations, and legislation governing academic and written work.
Disclaimer
Great care has been taken in the preparation of this document; however, the contents are provided "as is" without any express or
implied representations or warranties. The author accepts no responsibility or liability for any actions taken based on the
information contained within this document. This document is intended solely for comparison, research, and reference purposes.
Reproduction, resale, or transmission of any part of this document, in any form or by any means, is strictly prohibited.
, +27 81 278 3372
QUESTION 01
a. How each approach schedules CPU-intensive and short interactive tasks
In the per-core run queue approach, each processor core has its own ready queue,
so tasks are placed on a specific core and that core selects tasks only from its own
queue. CPU-intensive tasks, such as video encoding, may continue running on the
same core for long periods, which can improve cache use because the process often
reuses data already stored close to that core. Short interactive tasks are also placed
in one of the core queues, but their response time may suffer if they are placed
behind long CPU-intensive tasks on a busy core.
In the shared run queue approach, all ready processes are kept in one global
queue, and any free processor core can take the next available task from that queue.
CPU-intensive tasks are selected from the same queue as interactive tasks, so the
system can spread work across all eight cores more easily. Short interactive tasks
may get quicker attention because an idle core can take them directly from the global
queue instead of waiting for one specific overloaded core to finish its work. The
question in TL102 asks this in the context of an eight-core server that runs both
CPU-intensive and short interactive tasks.
b. Advantages and disadvantages of each scheduling approach
Scheduling Advantages Disadvantages
approach
Per-core It improves cache performance Some cores can become
run queues because a process can remain overloaded while other cores
on the same core and reuse remain idle if tasks are not moved
cached data. It also reduces properly. It can also be less fair
contention because each core because a short task may wait
manages its own queue instead behind long CPU-bound tasks in
of many cores fighting for one one queue while another core is
shared queue. free.
Disclaimer
Great care has been taken in the preparation of this document; however, the contents are provided "as is"
without any express or implied representations or warranties. The author accepts no responsibility or
liability for any actions taken based on the information contained within this document. This document is
intended solely for comparison, research, and reference purposes. Reproduction, resale, or transmission
of any part of this document, in any form or by any means, is strictly prohibited.
, +27 81 278 3372
Shared run It gives better load balancing It can create contention because all
queue because all cores take tasks cores must access the same
from the same global queue. It queue, especially on a busy server.
can also improve fairness It can also reduce cache
because all ready tasks are performance because a process
visible to the scheduler in one may move between cores and lose
place. the benefit of data already cached
on one core.
c. Easier workload balancing
The shared run queue approach makes workload balancing easier because all
eight cores draw work from the same global queue. When one core becomes idle, it
can immediately take the next ready task without needing to steal work from another
core’s private queue. This avoids the problem where one core has many waiting
tasks while another core has nothing to do.
d. Recommended approach
For this server, I would recommend per-core run queues with load balancing,
rather than a purely shared run queue. This approach is better for performance
because each core can schedule its own tasks with less locking and less contention.
It also supports better cache usage because CPU-intensive tasks can stay on the
same core and continue using data already stored in that core’s cache. Fairness can
still be protected if the operating system includes periodic load balancing, where
tasks are moved from overloaded cores to idle or less busy cores.
A shared run queue is simpler for balancing work, but it may become a bottleneck
when many cores try to access the same queue at the same time. Since the server
has eight processor cores and must handle both long CPU-intensive work and short
user requests, per-core queues with proper task migration give a stronger balance
between speed, cache efficiency and fair access to CPU time.
Disclaimer
Great care has been taken in the preparation of this document; however, the contents are provided "as is"
without any express or implied representations or warranties. The author accepts no responsibility or
liability for any actions taken based on the information contained within this document. This document is
intended solely for comparison, research, and reference purposes. Reproduction, resale, or transmission
of any part of this document, in any form or by any means, is strictly prohibited.
Assignment 2 2026
Unique number:
Due Date: June 2026
QUESTION 01
a. How each approach schedules CPU-intensive and short interactive tasks
In the per-core run queue approach, each processor core has its own ready queue, so
tasks are placed on a specific core and that core selects tasks only from its own queue.
CPU-intensive tasks, such as video encoding, may continue running on the same core for
long periods, which can improve cache use because the process often reuses data already
stored close to that core. Short interactive tasks are also placed in one of the core queues,
but their response time may suffer if they are placed behind long CPU-intensive tasks on a
busy core.
In the shared run queue approach, all ready processes are kept in one global queue, and
any free processor core can take the next available task from that queue. CPU-intensive
tasks are selected from the same queue as interactive tasks, so the system can spread work
across all eight cores more easily. Short interactive tasks may get quicker attention because
an idle core can take them directly from the global queue instead of waiting for one specific
Terms of use
overloaded core to finish its work. The question in TL102 asks this in the context of an eight-
By making use of this document you agree to:
core server Use this document
that runs both CPU-intensive as a guide
and short for learning,
interactive comparison and reference purpose,
tasks.
Terms of use
Not to duplicate, reproduce and/or misrepresent the contents of this document as your own work,
By making use of this document you agree to:
Use this document
Fully accept the consequences
solely as a guide forshould you plagiarise
learning, or and
reference, misuse this document.
comparison purposes,
Ensure originality of your own work, and fully accept the consequences should you plagiarise or misuse this document.
Comply with all relevant standards, guidelines, regulations, and legislation governing academic and written work.
Disclaimer
Great care has been taken in the preparation of this document; however, the contents are provided "as is" without any express or
implied representations or warranties. The author accepts no responsibility or liability for any actions taken based on the
information contained within this document. This document is intended solely for comparison, research, and reference purposes.
Reproduction, resale, or transmission of any part of this document, in any form or by any means, is strictly prohibited.
, +27 81 278 3372
QUESTION 01
a. How each approach schedules CPU-intensive and short interactive tasks
In the per-core run queue approach, each processor core has its own ready queue,
so tasks are placed on a specific core and that core selects tasks only from its own
queue. CPU-intensive tasks, such as video encoding, may continue running on the
same core for long periods, which can improve cache use because the process often
reuses data already stored close to that core. Short interactive tasks are also placed
in one of the core queues, but their response time may suffer if they are placed
behind long CPU-intensive tasks on a busy core.
In the shared run queue approach, all ready processes are kept in one global
queue, and any free processor core can take the next available task from that queue.
CPU-intensive tasks are selected from the same queue as interactive tasks, so the
system can spread work across all eight cores more easily. Short interactive tasks
may get quicker attention because an idle core can take them directly from the global
queue instead of waiting for one specific overloaded core to finish its work. The
question in TL102 asks this in the context of an eight-core server that runs both
CPU-intensive and short interactive tasks.
b. Advantages and disadvantages of each scheduling approach
Scheduling Advantages Disadvantages
approach
Per-core It improves cache performance Some cores can become
run queues because a process can remain overloaded while other cores
on the same core and reuse remain idle if tasks are not moved
cached data. It also reduces properly. It can also be less fair
contention because each core because a short task may wait
manages its own queue instead behind long CPU-bound tasks in
of many cores fighting for one one queue while another core is
shared queue. free.
Disclaimer
Great care has been taken in the preparation of this document; however, the contents are provided "as is"
without any express or implied representations or warranties. The author accepts no responsibility or
liability for any actions taken based on the information contained within this document. This document is
intended solely for comparison, research, and reference purposes. Reproduction, resale, or transmission
of any part of this document, in any form or by any means, is strictly prohibited.
, +27 81 278 3372
Shared run It gives better load balancing It can create contention because all
queue because all cores take tasks cores must access the same
from the same global queue. It queue, especially on a busy server.
can also improve fairness It can also reduce cache
because all ready tasks are performance because a process
visible to the scheduler in one may move between cores and lose
place. the benefit of data already cached
on one core.
c. Easier workload balancing
The shared run queue approach makes workload balancing easier because all
eight cores draw work from the same global queue. When one core becomes idle, it
can immediately take the next ready task without needing to steal work from another
core’s private queue. This avoids the problem where one core has many waiting
tasks while another core has nothing to do.
d. Recommended approach
For this server, I would recommend per-core run queues with load balancing,
rather than a purely shared run queue. This approach is better for performance
because each core can schedule its own tasks with less locking and less contention.
It also supports better cache usage because CPU-intensive tasks can stay on the
same core and continue using data already stored in that core’s cache. Fairness can
still be protected if the operating system includes periodic load balancing, where
tasks are moved from overloaded cores to idle or less busy cores.
A shared run queue is simpler for balancing work, but it may become a bottleneck
when many cores try to access the same queue at the same time. Since the server
has eight processor cores and must handle both long CPU-intensive work and short
user requests, per-core queues with proper task migration give a stronger balance
between speed, cache efficiency and fair access to CPU time.
Disclaimer
Great care has been taken in the preparation of this document; however, the contents are provided "as is"
without any express or implied representations or warranties. The author accepts no responsibility or
liability for any actions taken based on the information contained within this document. This document is
intended solely for comparison, research, and reference purposes. Reproduction, resale, or transmission
of any part of this document, in any form or by any means, is strictly prohibited.
