Method and apparatus for dynamically allocating resources for QoS assurance and high-efficiency workload integration in a multiplexed memory system.

JP2026097758APending Publication Date: 2026-06-16UNIST (ULSAN NAT INST OF SCI & TECH)

Patent Information

Authority / Receiving Office
JP · JP
Patent Type
Applications
Current Assignee / Owner
UNIST (ULSAN NAT INST OF SCI & TECH)
Filing Date
2025-11-26
Publication Date
2026-06-16

Smart Images

  • Figure 2026097758000001_ABST
    Figure 2026097758000001_ABST
Patent Text Reader

Abstract

This invention provides a method and apparatus for dynamically allocating resources in a multiplexed memory system to ensure Quality of Service (QoS) and achieve high-efficiency workload integration. [Solution] The method involves allocating resources to latency-critical (LC) applications and batch applications configured on an application server based on pre-stored system states determined at pre-set intervals using a resource assignor, collecting performance data of the LC and batch applications to which resources have been allocated using a performance monitor, searching for system states based on the collected performance data of the LC and batch applications using a system state space explorer, and determining subsequent system states that are expected to have improved processing capacity or satisfy QoS compared to the processing capacity based on the pre-stored system states, based on the search.
Need to check novelty before this filing date? Find Prior Art

Claims

1. A method for dynamically allocating resources for Quality of Service (QoS) assurance and high-efficiency workload consolidation in a multiple isolated memory system, executed by the processor of an isolated memory server, The steps include: allocating resources to latency-critical (LC) applications and batch applications configured on an application server based on a pre-stored system state determined at pre-set intervals using a resource assignor; The steps include: using a performance monitor to collect performance data for the LC application and batch application to which the aforementioned resources are allocated; The steps include: using a system state space explorer to explore the system state based on the performance data of the collected LC application and batch application; The steps include determining a subsequent system state that is expected to have a processing capacity that is higher than the processing capacity based on the pre-stored system state, or that satisfies the QoS, based on the search described above. Methods that include...

2. The step of collecting the aforementioned performance data is: The steps include collecting the load and tail latency of the LC application using the performance monitor, The steps include: collecting the processing volume of the batch application using the performance monitor; The method according to claim 1, including the method described in claim 1.

3. The step of exploring the aforementioned system state is: The steps include: calculating a slug based on the tail latency of the collected LC application using the system state space searcher; The steps include: using the system state space searcher, inputting the slug and the pre-stored system state into the getNextSystemState function to derive the subsequent system state; The method according to claim 2, including the method described in claim 2.

4. The step of deriving the subsequent system state is: The steps include determining a donor application and a receiver application based on the slug and the pre-stored system state, The steps include reallocating resources based on the previously stored system state and the determined donor and receiver applications, The method according to claim 3, including the method described in claim 3.

5. The step of determining the donor application and receiver application is: The steps include: determining the donor application from among the LC application and the batch application based on the candidate donor application for the LC application determined by inputting the slug and the pre-stored system state into the getCandidateLCDonor function; The steps include: determining the receiver application from among the LC application and the batch application based on the candidate receiver application for the LC application determined by inputting the slug and the pre-stored system state into the getCandidateLCReceiver function; The method according to claim 4, including the method described in claim 4.

6. The step of determining the donor application is, The LC application that has the largest slug among the slugs that exceeds the upper threshold and whose assigned weight is greater than the minimum weight is selected as the donor, The method according to claim 5, further comprising the step of determining a batch application as a donor if all LC applications have a minimum weight value or the slug is below a higher threshold.

7. The step of determining the receiver application is: An LC application is determined to be the receiver if it has the smallest slug among the slugs that is below the lower threshold and whose assigned weight is less than the maximum weight, or The method according to claim 5, further comprising the step of determining a batch application as a receiver if all LC applications have the maximum weight value or if the slug is greater than or equal to a lower threshold.

8. The method according to claim 3, wherein the step of calculating the slug includes the step of normalizing the difference between a pre-stored target tail latency and the tail ray turn time to calculate the slug.

9. The method according to claim 3, further comprising the step of adding the subsequent system state to a history buffer if the subsequent system state is a system state that has been derived for the first time.

10. The method according to claim 3, further comprising the step of determining the subsequent system state in a history buffer if the subsequent system state is a previously derived system state, and switching to an idle phase in which only the performance monitor and the resource assigner are executed.

11. A device for dynamically allocating resources for QoS (Quality of Service) assurance and high-efficiency workload integration in a multiplexed memory system, A device including a processor that uses a resource assignor to allocate resources to latency-critical (LC) applications and batch applications configured on an application server based on pre-stored system states determined at pre-set intervals; uses a performance monitor to collect performance data of the LC and batch applications to which the resources have been allocated; uses a system state space explorer to explore system states based on the collected performance data of the LC and batch applications; and determines a subsequent system state based on the exploration that is expected to have a processing volume improved from the processing volume based on the pre-stored system states or that satisfies the QoS.

12. The apparatus according to claim 11, wherein the processor collects the load and tail latency of the LC application using the performance monitor and collects the processing volume of the batch application using the performance monitor.

13. The apparatus according to claim 12, wherein the processor calculates a slug based on the tail latency of the collected LC application using the system state space searcher, and uses the system state space searcher to input the slug and the pre-stored system state into the getNextSystemState function to derive the subsequent system state.

14. The apparatus according to claim 13, wherein the processor determines a donor application and a receiver application based on the slug and the pre-stored system state, and reallocates resources based on the pre-stored system state and the determined donor application and receiver application.

15. The apparatus according to claim 14, wherein the processor determines the donor application from among the LC application and the batch application based on a candidate donor application for the LC application determined by inputting the slug and the pre-stored system state to the getCandidateLCDonor function, and determines the receiver application from among the LC application and the batch application based on a candidate receiver application for the LC application determined by inputting the slug and the pre-stored system state to the getCandidateLCReceiver function.

16. The apparatus according to claim 15, wherein the processor determines an LC application as a donor if it has the largest slug among the slugs that exceeds a higher threshold and has an assigned weight value greater than the minimum weight value, or if all LC applications have the minimum weight value or the slugs are less than or equal to the higher threshold.

17. The apparatus according to claim 15, wherein the processor determines an LC application as a receiver if it has the smallest slug among the slugs and is below a lower threshold, and the assigned weight is less than the maximum weight, or if all LC applications have the maximum weight or the slug is greater than or equal to a lower threshold.

18. The apparatus according to claim 13, wherein the processor calculates a slug by normalizing the difference between a pre-stored target tail latency and the tail ray turn time.

19. The apparatus according to claim 13, wherein the processor adds the subsequent system state to the history buffer if the subsequent system state is a system state that has been derived for the first time.

20. The apparatus according to claim 13, wherein the processor determines the subsequent system state in the history buffer if the subsequent system state is a previously derived system state, and switches to an idle phase in which only the performance monitor and the resource assigner are executed.