Virtual machine memory area allocation method and device, electronic equipment and storage medium

Abstract

The invention relates to the field of computers, in particular to a virtual machine memory area allocation method and device, electronic equipment and a storage medium. The method comprises the following steps: firstly, acquiring opposite-end equipment for performing docking negotiation on a current virtual machine, and obtaining version information of a data plane development suite deployed on the opposite-end equipment; then, the data plane development suite is verified according to the version information, if a verification result shows that verification is passed, a query request is sent to the data plane development suite, the data plane development suite is prompted to determine the currently loadable maximum memory area number based on the request, the limitation that only eight memory-area mapping is supported originally is broken through, and a larger loadable number is obtained. And then, the maximum memory area number fed back is received, and the memory area allocation layout of the current virtual machine is planned by using the number, so that the vnuma number of the virtual machine is not limited by the previous situation and can be reasonably expanded according to the newly obtained number, and the situation that the hot plug memory function is difficult to realize due to the limitation of the memory-region number is avoided.

Description

Technical Field

[0001] The present invention relates to the field of computers, and in particular to a method, device, electronic device and storage medium for allocating a virtual machine memory area. Background Art

[0002] At a time when QEMU-KVM virtualization is booming, the realization and optimization of network functions has always been a key research direction, among which the Open vSwitchwith Data Plane Development Kit (OVS-DPDK) solution stands out and attracts much attention. The traditional OVS-Kernel solution has many performance bottlenecks when processing network data in kernel mode, such as frequent system calls and kernel context switching, which limits the efficiency of network transmission. In contrast, OVS-DPDK cleverly uses user-mode drivers to bypass kernel-mode overhead and directly manipulate hardware resources, greatly reducing unnecessary delays; the use of large page mechanisms reduces the number of page table entries, reduces the complexity of memory management, and speeds up memory access; the design of lock-free queues avoids the blockage caused by lock competition during multi-threaded concurrency and improves data transmission throughput; the CPU polling mode replaces interrupt drivers, allowing the CPU to be ready to process network data at all times, further enhancing the timeliness of response. With these advantages, OVS-DPDK has already occupied a mainstream position in the QEMU-KVM virtualization scenario.

[0003] Currently, OVS-DPDK only supports up to 8 memory-region mappings, causing virtual machines using OVS-DPDK network cards to face many difficulties: on the one hand, the number of vnuma of the virtual machine is limited. In most cases, vnum0 needs to be occupied additionally, resulting in a maximum of 7 vnuma supported, which affects the expansion of virtual machines; on the other hand, the hot-plug memory function is limited. Each hot-plug memory occupies a memory-region. When there are many vnuma, hot-plug memory is almost impossible to achieve; furthermore, each update of memory-region requires updating all memory mappings, resulting in significant network interruption time and seriously interfering with network communication stability. Summary of the invention

[0004] In view of this, an embodiment of the present invention provides a method, device, electronic device and storage medium for allocating a virtual machine memory area to solve the problem that the current OVS-DPDK only supports the mapping of up to 8 memory-regions, causing virtual machines using OVS-DPDK network cards to face many difficulties.

[0005] In a first aspect, an embodiment of the present invention provides a method for allocating a virtual machine memory area, the method comprising:

[0006] Obtaining a peer device with which the current virtual machine is to perform docking negotiation, and obtaining version information of a data plane development kit deployed on the peer device;

[0007] Verifying the data plane development kit based on the version information to obtain a verification result;

[0008] If the verification result is that the verification is passed, a query request is sent to the data plane development kit, wherein the data plane development kit determines the maximum number of memory areas that can be currently carried based on the query request;

[0009] Receive the maximum number of memory areas fed back by the data plane development kit based on the query request, and use the maximum number of memory areas to plan the allocation layout of the memory areas of the current virtual machine.

[0010] Further, the step of obtaining a peer device with which the current virtual machine is to perform docking negotiation, and obtaining version information of a data plane development kit deployed on the peer device, includes:

[0011] Searching for a peer device for docking and negotiation with the current virtual machine based on a preset communication mechanism;

[0012] Initiating a version acquisition request to the peer device, wherein the peer device feeds back version information of the data plane development kit deployed by the peer device based on the version acquisition request;

[0013] Receive the version information fed back by the opposite device.

[0014] Further, the verifying the data plane development kit based on the version information to obtain a verification result includes:

[0015] Obtaining a pre-configured dynamic memory region protocol characteristic, wherein the dynamic memory region protocol characteristic includes a preset version rule for increasing an upper limit of a memory region;

[0016] Matching the version information with the preset version rule to obtain the verification result;

[0017] If the version information matches the preset version rule, the verification result is a passed verification; or, if the version information matches the preset version rule, the verification result is a failed verification.

[0018] Furthermore, the planning of the allocation layout of the memory area of ​​the current virtual machine by using the maximum number of memory areas includes:

[0019] Obtaining each task running in the current virtual machine and the task characteristics of each task;

[0020] Determining a priority level corresponding to the task based on the task characteristics;

[0021] A corresponding number of sub-regions are obtained from the maximum number of memory regions according to the division priority, and a corresponding number of sub-regions are allocated from the memory region of the current virtual machine to corresponding tasks.

[0022] Furthermore, after allocating a corresponding number of sub-areas in the memory area of ​​the current virtual machine to corresponding tasks, the method further includes:

[0023] Real-time monitoring of key indicator data of sub-areas corresponding to each task in the memory area;

[0024] Analyze the key indicator data to determine whether the sub-regions corresponding to each task meet the regional optimization conditions;

[0025] If the area optimization condition is met, a memory area optimization strategy is obtained according to the optimization type hit by the key indicator data, and a memory area optimization operation is performed on the sub-area corresponding to the task according to the memory area optimization strategy.

[0026] Furthermore, performing a memory region optimization operation on the sub-region corresponding to the task according to the memory region optimization strategy includes:

[0027] If the memory area optimization strategy is memory allocation, then locate the sub-area marked as providing idle memory, and migrate the corresponding memory unit from the idle sub-area to the sub-area corresponding to the task in urgent need of memory according to the established allocation amount;

[0028] If the memory area optimization strategy is to shrink the range of the idle sub-area, the boundary of the sub-area in the entire memory layout is adjusted according to a preset shrinking ratio, and the corresponding memory space is released.

[0029] Furthermore, after planning the allocation layout of the memory area of ​​the current virtual machine using the maximum number of memory areas, the method further includes:

[0030] Detecting whether the layout of the memory area in the current virtual machine is updated;

[0031] If the layout of the memory area is updated, extracting the layout change information corresponding to the memory area;

[0032] The layout change information is sent to a data plane development kit deployed on the opposite device, wherein the data plane development kit is used to determine the changed memory area based on the layout change information and establish a mapping relationship between the changed memory area and the physical memory address.

[0033] In a second aspect, an embodiment of the present invention provides a device for allocating a virtual machine memory area, the device comprising:

[0034] An acquisition module is used to acquire a peer device with which the current virtual machine is to perform docking negotiation, and to acquire version information of a data plane development kit deployed on the peer device;

[0035] A verification module, used to verify the data plane development kit based on the version information to obtain a verification result;

[0036] A sending module, configured to send a query request to the data plane development kit if the data plane development kit passes the verification, wherein the data plane development kit determines the maximum number of memory areas that can be currently carried based on the query request;

[0037] A planning module is used to receive the maximum number of memory areas fed back by the data plane development kit based on the query request, and use the maximum number of memory areas to plan the allocation layout of the memory areas of the current virtual machine.

[0038] In a third aspect, an embodiment of the present invention provides an electronic device, comprising: a memory and a processor, the memory and the processor being communicatively connected to each other, computer instructions being stored in the memory, and the processor executing the method of the first aspect or any corresponding embodiment thereof by executing the computer instructions.

[0039] In a fourth aspect, an embodiment of the present invention provides a computer-readable storage medium having computer instructions stored thereon, the computer instructions being used to enable a computer to execute the method of the first aspect or any corresponding embodiment thereof.

[0040] The embodiment of the present application first obtains the opposite device for the current virtual machine to conduct docking negotiation, and obtains the version information of the data plane development kit deployed on the opposite device. Then, the data plane development kit is verified based on this version information to obtain the verification result. If the verification result is passed, a query request is sent to it, prompting the data plane development kit to determine the maximum number of memory regions that can be carried based on the request. This step breaks through the limitation of only supporting 8 memory-region mappings, and can obtain a larger number of carrying capacity. Then, the maximum number of memory regions fed back is received, and this number is used to plan the memory area allocation layout of the current virtual machine, so that the number of vnuma of the virtual machine is no longer limited by the previous situation, and can be reasonably expanded according to the newly obtained number, and the hot-plug memory function will not be difficult to implement due to the number limit of memory-region. At the same time, when updating the memory area, since it is based on a layout after reasonable planning, it is not necessary to update all memory mappings every time as before, thereby avoiding obvious network interruption time and effectively ensuring the stability of network communication. BRIEF DESCRIPTION OF THE DRAWINGS

[0041] In order to more clearly illustrate the specific implementation methods of the present invention or the technical solutions in the prior art, the drawings required for use in the specific implementation methods or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are some implementation methods of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0042] Figure 1 is a flow chart of a method for allocating a virtual machine memory area according to some embodiments of the present invention;

[0043] Figure 2 is a flowchart of a virtual machine negotiation and memory area upper limit query method according to some embodiments of the present invention;

[0044] Figure 3 is a structural block diagram of a device for allocating a virtual machine memory area according to an embodiment of the present invention;

[0045] Figure 4 It is a schematic diagram of the hardware structure of the electronic device according to an embodiment of the present invention. DETAILED DESCRIPTION

[0046] In order to make the purpose, technical solution and advantages of the embodiments of the present invention clearer, the technical solution in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative work are within the scope of protection of the present invention.

[0047] According to an embodiment of the present invention, a method, device, electronic device and storage medium for allocating a virtual machine memory area are provided. It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer executable instructions, and although a logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in an order different from that shown here.

[0048] In this embodiment, a method for allocating a virtual machine memory area is provided. Figure 1 is a flowchart of a method for allocating a virtual machine memory area according to an embodiment of the present invention. Figure 1 As shown, the process includes the following steps:

[0049] Step S101, obtaining a peer device with which the current virtual machine is to perform docking negotiation, and obtaining version information of a data plane development kit deployed on the peer device.

[0050] In the embodiment of the present application, a function module related to the new DYNAMIC_MEMRGNprotocolfeature (dynamic memory region protocol feature) is started in the current virtual machine. This feature is a key part specifically used to identify whether the peer device supports the technical solution and subsequent related interactive operations. Through the built-in protocol interaction program, it is in a state of being ready to communicate with the peer device at any time and detect the relevant information of the peer.

[0051] The current virtual machine uses the above-mentioned protocol features to send a detection request to the target device with which it is negotiating. This request is intended to trigger the peer device to feedback relevant information about itself, including the version information of the data plane development kit deployed on it. The request is encapsulated according to the established communication protocol format and contains specific identification fields to indicate that it is a version detection request and other key content to ensure that the peer device can accurately identify and process it accordingly.

[0052] After receiving the detection request sent by the current virtual machine, the peer device will parse the request content and prepare the version information of its own data plane development kit according to the protocol requirements. Then, the version information will be packaged according to the unified communication protocol format and sent back to the current virtual machine. The current virtual machine will continue to monitor the corresponding communication port through the corresponding receiving module, waiting for the feedback data from the peer device. Once the feedback data packet is received, it will start the next step of parsing and processing.

[0053] After the current virtual machine receives the feedback data packet from the peer device, it calls a special parsing program to disassemble the data packet. According to the pre-defined information structure and field meaning, it accurately extracts the key version information about the data plane development kit, such as version number, version release time, and whether it is an official version, from the data packet, and stores the extracted information in the storage area specified inside the virtual machine, so that it can subsequently determine whether the peer supports this technical solution based on this version information, and carry out other related memory management operations and other processes.

[0054] In an embodiment of the present application, obtaining a peer device with which the current virtual machine is to perform docking negotiation, and obtaining version information of a data plane development kit deployed on the peer device, includes the following steps A1-A3:

[0055] Step A1: searching for a peer device for connection negotiation with the current virtual machine based on a preset communication mechanism.

[0056] Specifically, in the current virtual machine's operating environment, the process of searching for the peer device is started according to a pre-set communication mechanism. This communication mechanism covers elements such as specific network protocols, port numbers, and identification rules. The relevant modules in the virtual machine system will follow these established contents, broadcast detection signals in the network environment in which it is located, or actively search for other devices that are associated with it and need to be connected and negotiated along the preset connection link. For example, scan according to the established IP segment range, or accurately match the corresponding peer device based on previously configured key information such as device identification and service name, so as to gradually lock in the target peer devices with which further interaction is to be carried out, involving technical solutions such as memory area management.

[0057] Step A2: Initiate a version acquisition request to the peer device, wherein the peer device feeds back version information of the data plane development kit deployed by the peer device based on the version acquisition request.

[0058] Specifically, after successfully locking the peer device, the current virtual machine will start a special request sending module and carefully construct a version acquisition request message based on a unified communication protocol format. This request message contains key content such as specific fields indicating the intent of the request, its own identification information, and the protocol version followed, to ensure that the peer device can accurately identify that this is a request from the current virtual machine to obtain the version information of its data plane development kit. Subsequently, the request is accurately sent to the peer device through an established or preset communication channel. After receiving this request, the internal processing program of the peer device will respond immediately, extract the version number, release time, function version and other detailed version information of the deployed data plane development kit from its own system configuration and related storage areas, and organize this information into a feedback message in accordance with the same communication protocol specification, ready to be sent back to the current virtual machine.

[0059] Step A3: receiving version information fed back by the peer device.

[0060] Specifically, the current virtual machine has a monitoring module specifically used to receive external feedback information. This module is always in an activated state and continuously monitors the corresponding communication port and the communication protocol channel followed. When the peer device sends a feedback message containing version information, this monitoring module can capture the signal in time and receive the transmitted data packet. Then, the matching parsing program will be called to accurately disassemble the version information of the data plane development kit deployed by the peer device from the received data packet according to the pre-set message structure and field definition, such as the specific version number, whether it is the latest version, the corresponding version update time, etc., and the parsed information will be properly stored in the designated data area inside the virtual machine, which provides a key basis for subsequent judgment of whether the peer device supports the relevant technical solution and conducts further memory area management operations.

[0061] Step S102: verify the data plane development kit based on the version information to obtain a verification result.

[0062] In an embodiment of the present application, the data plane development kit is verified based on the version information to obtain a verification result, including: obtaining a pre-configured dynamic memory area protocol feature, wherein the dynamic memory area protocol feature includes a preset version rule for increasing the upper limit of the memory area; matching the version information with the preset version rule to obtain a verification result; wherein, if the version information matches the preset version rule, the verification result is a passed verification; or, if the version information matches the preset version rule, the verification result is a failed verification.

[0063] In the current virtual machine or related memory management system, there are pre-configured setting modules and storage areas related to the dynamic memory region protocol feature. When the system starts, the corresponding initialization program will load these configuration information, or when the feature needs to be used for related verification and other operations, a special reading program will be triggered. These programs will accurately locate and extract the details of the dynamic memory region protocol feature according to the established configuration file path, database storage location, etc.

[0064] Among them, the preset version rules for increasing the upper limit of the memory area, as a key part of the protocol characteristics, will clearly specify the version requirements of the data plane development kit on the peer device that supports increasing the upper limit of the memory area. For example, it may specifically point out a certain version number range (such as greater than or equal to a specific version number and less than a certain update version number), or require certain specific functional module versions and other conditions. These rule information will be completely extracted and stored in the temporary data structure in the memory for subsequent matching and comparison operations, waiting for the version information to be passed in to carry out the verification process.

[0065] After obtaining the version information of the data plane development kit deployed on the peer device (such as the version number, function version and other details obtained through the process of initiating a request to the peer device and receiving feedback as described above), the matching and comparison operation will be initiated. The system will check the key elements of the received version information, such as the version number, the specific function modules included, etc., against the preset version rules for increasing the upper limit of the memory area in the pre-configured dynamic memory area protocol feature.

[0066] If the version number in the version information falls within the version number range specified by the preset version rules and has the corresponding functional modules and other conditions required by the rules, it means that the version information matches the preset version rules. At this time, the verification result is passed, indicating that the peer device meets the requirements for implementing the relevant technical solutions for increasing the upper limit of the memory area. The corresponding memory area management operations can be carried out as planned, such as querying a larger memory area upper limit value and other processes.

[0067] On the contrary, if the version number in the version information is lower than the minimum version number required by the preset version rules, or key elements such as specific functional modules required by the rules are missing, that is, the version information does not match the preset version rules, then the verification result is verification failure, which means that the current version of the peer device cannot support the relevant technical solutions for increasing the upper limit of the memory area. In order to ensure the compatibility and stability of the system, subsequent memory management operations that rely on this condition cannot be carried out rashly. It may be necessary to prompt the operation and maintenance personnel to consider upgrading the relevant package version of the peer device, or take other adaptation measures to deal with it.

[0068] Step S103: If the verification result is passed, a query request is sent to the data plane development kit, wherein the data plane development kit determines the maximum number of memory areas that can be currently carried based on the query request.

[0069] In the embodiment of the present application, after the previous steps, the version information of the data plane development kit deployed on the peer device is matched with the preset version rules, and the verification result is obtained as passed, which means that the peer device meets the basic conditions for implementing the relevant technical solutions (such as operations involving increasing the upper limit of the memory area). At this time, on the current virtual machine side, the corresponding memory management control module will immediately start the subsequent operation process and prepare to send a query request to the data plane development kit of the peer.

[0070] First, the internal request building program is called, which organizes the query request content according to the established communication protocol specification. This communication protocol specification specifies the format of the request message, the necessary fields included, and the data type of each field. For example, there will be a specific identification field at the beginning of the request message to indicate that this is a request to query the maximum number of memory areas. At the same time, it will also include some identification information of the current virtual machine itself, such as the unique number of the virtual machine, the protocol version followed, etc., so that the peer device can accurately identify the source and purpose of the request.

[0071] Through the established or pre-configured communication channel, the carefully constructed query request is accurately sent to the data plane development kit at the other end. This communication channel ensures the stability and accuracy of data transmission. It may be based on network protocols (such as TCP / IP protocols, etc.) and uses specific port numbers for communication to avoid interference from other irrelevant network traffic. During the sending process, the system will also monitor the sending status in real time to ensure that the request reaches the opposite device completely and in a timely manner. If there is an abnormal situation such as sending failure, it will be resent according to the preset retry mechanism to ensure that the query request can successfully reach the target data plane development kit.

[0072] After the data plane development kit on the other end receives the query request from the current virtual machine, its internal processing program will quickly start the response mechanism. First, it will parse the request message and accurately extract the key information in the request according to the agreed protocol format to confirm that this is a request to query the maximum number of memory areas.

[0073] Then, it starts the internal resource evaluation and calculation process to determine the maximum number of memory areas that it can currently carry. This process involves comprehensive consideration of multiple factors, including its own hardware resources (such as physical memory capacity, memory allocation architecture, etc.), software configuration (such as memory management strategy, occupied memory area, etc.), and the current operating status of the system (such as whether there are high-load tasks that affect memory allocation, etc.). For example, it will count the current free physical memory space, combined with the preset minimum and maximum allocatable range of each memory area, as well as the memory resources occupied by other key businesses that are running, and analyze and calculate through internal algorithms to obtain the maximum number of memory areas that can be provided to the current virtual machine for allocation without affecting the overall stable operation of the system.

[0074] Finally, the calculated maximum number of memory areas is encapsulated according to the same communication protocol specification to form a response message, which is then sent back to the current virtual machine through the communication channel so that the current virtual machine can obtain this key value and carry out subsequent memory area allocation and management work based on it.

[0075] Step S104, receiving the maximum number of memory areas fed back by the data plane development kit based on the query request, and planning the allocation layout of the memory area of ​​the current virtual machine using the maximum number of memory areas.

[0076] In the embodiment of the present application, the allocation layout of the memory area of ​​the current virtual machine is planned by using the maximum number of memory areas, including the following steps B1-B3:

[0077] Step B1, obtaining each task running in the current virtual machine and the task characteristics of each task.

[0078] Specifically, in the current virtual machine's operating environment, there is a dedicated task management and monitoring module that tracks each running task in real time. It interacts with the virtual machine's operating system kernel and various application program interfaces to obtain a detailed task list, which covers all the information on the tasks being executed, from core business applications to various background auxiliary programs.

[0079] For each task, further collect its related task characteristics. These characteristics include but are not limited to the type of task (whether it is compute-intensive, I / O-intensive, or memory-intensive, etc.), the importance of the task (such as whether it is related to key business processes, whether it affects the overall stability of the system, etc.), the execution cycle of the task (whether it is a long-term continuous operation or a short-term task that is executed intermittently), and the frequency of data interaction of the task (whether it frequently reads and writes a large amount of data or occasionally interacts with a small amount of data, etc.). By analyzing the resource usage, behavior patterns, and other aspects during the task operation, the unique task characteristics of each task are comprehensively sorted out, laying the foundation for subsequent priority determination.

[0080] Step B2: determining the priority level of the task based on the task characteristics.

[0081] Specifically, after obtaining each task and its task characteristics, the priority determination process is started. This process will be carried out according to a set of pre-set priority determination rules. In terms of the type of task, if it is a computationally intensive task, such as complex data modeling, encryption and decryption operations, etc., it is usually given a higher priority because it is highly dependent on CPU resources and cannot be easily interrupted during operation; for I / O intensive tasks, such as database query operations that frequently read and write disk files, etc., considering its requirements for data transmission efficiency and the possibility of being suspended due to waiting for I / O operations, the priority will be comprehensively determined based on the specific I / O busyness and other conditions, and is generally at a medium level; for memory intensive tasks, the rationality of their memory usage and the degree of impact on other tasks must be further considered to determine the priority.

[0082] Considering the importance of tasks, those tasks that are directly related to core business processes and will seriously affect the overall function and stability of the system once problems occur will undoubtedly be classified as high priority; in contrast, auxiliary background tasks, such as timed cleaning of temporary files and updating system logs, will have a relatively low priority. The execution cycle of tasks will also affect the priority determination. Tasks that run continuously for a long time and play an important supporting role in the continuous service of the system will have a higher priority than short-term tasks that are executed intermittently.

[0083] In addition, tasks with high data interaction frequency are often assigned relatively high priorities in order to ensure smooth data flow. Taking into account the above-mentioned task characteristics, according to the corresponding weight ratio (these weights are also configured in advance according to the overall operation requirements of the system), through calculation and evaluation, the corresponding priority is finally determined for each task, forming a clear priority sorting list, clarifying which tasks have higher priority in resource acquisition such as memory allocation.

[0084] Step B3, obtaining a corresponding number of sub-regions from the maximum number of memory regions according to the division priority, and allocating a corresponding number of sub-regions from the memory region of the current virtual machine to corresponding tasks.

[0085] Specifically, first, based on the maximum number of memory areas previously obtained from the data plane development kit (this amount of data indicates the upper limit of the memory resources currently available for allocation), and referring to the priority order of each task that has been determined, the memory sub-area allocation operation is started.

[0086] For the highest priority task, a certain number of sub-regions are allocated to it according to its estimated memory demand (this demand can be determined by historical operation data, task preset configuration or professional memory estimation model). The determination of this number should fully meet the basic operation and performance guarantee requirements of the task, while avoiding waste of resources caused by over-allocation, which requires careful trade-offs in actual operations.

[0087] Then, the same operation is performed on subsequent tasks in descending order of priority. Each time a task is processed, the corresponding number of sub-regions is reasonably allocated from the maximum number of remaining allocatable memory regions according to its task characteristics and estimated memory requirements to ensure that each task can obtain adapted memory resources.

[0088] During the allocation process, precise operations will be performed through the memory management system inside the virtual machine to update the memory mapping table and record key information such as the sub-area range and starting address corresponding to each task, to ensure that each task can accurately access the memory area allocated to it during subsequent operation, and to achieve reasonable and orderly allocation of memory resources to meet the requirements of stable and efficient operation of different tasks in the virtual machine.

[0089] By acquiring each task running in the current virtual machine and their task characteristics, the embodiment of the present application can fully and deeply understand the unique needs and behavior patterns of each task during operation, such as whether it is computationally intensive and highly dependent on the CPU, or I / O intensive and focused on data transmission, etc., to lay a solid foundation for the subsequent reasonable allocation of resources; then, based on these task characteristics, the corresponding division priority of each task is determined, just as if the tasks are arranged in order on the "track" of resource acquisition, so that important and urgent tasks that have a great impact on the overall performance of the system can be given priority to obtain sufficient memory resources to avoid key tasks from being stuck or failing due to insufficient memory, and ensure the smooth operation of core business processes; finally, according to the division priority, a corresponding number of sub-areas are obtained from the maximum number of memory areas and allocated to the corresponding tasks. This approach realizes the refined and scientific allocation of memory resources, which can fully meet the memory requirements of high-priority tasks to ensure their efficient operation, and avoid excessive resource inclination to low-priority tasks. Waste, so that limited memory resources are optimally configured in the virtual machine, and the overall operation efficiency, stability and carrying capacity of various tasks of the virtual machine system are improved.

[0090] The embodiment of the present application first obtains the opposite device for the current virtual machine to conduct docking negotiation, and obtains the version information of the data plane development kit deployed on the opposite device. Then, the data plane development kit is verified based on this version information to obtain the verification result. If the verification result is passed, a query request is sent to it, prompting the data plane development kit to determine the maximum number of memory regions that can be carried based on the request. This step breaks through the limitation of only supporting 8 memory-region mappings, and can obtain a larger number of carrying capacity. Then, the maximum number of memory regions fed back is received, and this number is used to plan the memory area allocation layout of the current virtual machine, so that the number of vnuma of the virtual machine is no longer limited by the previous situation, and can be reasonably expanded according to the newly obtained number, and the hot-plug memory function will not be difficult to implement due to the number limit of memory-region. At the same time, when updating the memory area, since it is based on a layout after reasonable planning, it is not necessary to update all memory mappings every time as before, thereby avoiding obvious network interruption time and effectively ensuring the stability of network communication.

[0091] In an embodiment of the present application, after a corresponding number of sub-areas in the memory area of ​​the current virtual machine are allocated to corresponding tasks, the method also includes: real-time monitoring of key indicator data of the sub-areas corresponding to each task in the memory area; analyzing the key indicator data to determine whether the sub-areas corresponding to each task meet the area optimization conditions; if the area optimization conditions are met, obtaining a memory area optimization strategy based on the optimization type hit by the key indicator data, and performing memory area optimization operations on the sub-areas corresponding to the task according to the memory area optimization strategy.

[0092] Specifically, with the help of the underlying driver and kernel interface, the sub-areas corresponding to each task are continuously scanned to capture key indicator data. The memory usage rate is the first to be affected. It accurately presents the proportion of the memory capacity currently occupied by each sub-area to the total allocated memory, accurate to decimal places. For example, in the sub-area of ​​a video rendering task, the memory usage rate may instantly soar to 85% during the peak rendering period. The monitoring system will record this change in seconds; the reading and writing frequency should not be underestimated. The number of data writes and reads per unit time is counted in detail. When the database is frequently queried, the corresponding sub-area read frequency rises sharply. The monitoring tool captures such fluctuations in real time; it also covers data transmission delay, measuring the time it takes for data to be transmitted between the sub-area memory and other hardware levels. Once the delay increases abnormally, it indicates that the memory access link may be "jammed".

[0093] In addition, the degree of memory fragmentation is also included in the monitoring scope, analyzing the distribution of free memory blocks and identifying scattered and severely fragmented areas. Although such areas seem to have free memory, they are actually difficult to allocate and utilize efficiently. In addition, the CPU usage and disk I / O status of related tasks are also recorded. Because the memory is closely linked to the CPU and disk, if the corresponding sub-area memory is in a state of emergency under high CPU load, or if the disk is frequently read and written but stuck due to insufficient memory cache, clues can be found from the related indicators. All data is updated and collected every very short time (such as 1-2 seconds) and stored in the cache area to build a dynamic "portrait" of the real-time status of the memory sub-area for subsequent in-depth analysis.

[0094] After accumulating key indicator data for a certain period of time (such as 10 minutes), the intelligent analysis module "comes on stage". It has built-in complex algorithms and preset rules to examine the state of sub-regions from multiple dimensions. If the memory usage of a sub-region continues to exceed the set threshold (assuming that the core business task threshold is set to 90%) for several minutes, and the read and write frequency remains high, and the data transmission delay is seriously exceeded, combined with the associated CPU jams and disk overload conditions, it is basically determined that the sub-region has fallen into a "memory emergency" dilemma due to a sudden increase in business and tight resources, and urgently needs optimization; on the other hand, if a sub-region has a long-term memory usage rate of less than 10%, the read and write frequency is almost zero, the degree of fragmentation is low but there is no business activity, it is undoubtedly in an idle and wasteful state, and it also meets the optimization conditions.

[0095] Furthermore, from the analysis of business development trends, if it is known that a certain business is about to usher in a traffic peak, even if the current sub-region memory indicators are still acceptable, it is also considered to meet the optimization considerations if the subsequent pressure is predicted in advance; or the system detects hardware resource upgrades (such as adding new memory bars), compared with the existing memory allocation pattern, those sub-regions that have not kept up with the pace of resource expansion and have low utilization rates are also included in the list to be optimized. Through layer-by-layer analysis, each "problem sub-region" that needs to be optimized is accurately located to find the right target for subsequent strategy customization. If the regional optimization conditions are met, the memory area optimization strategy is obtained according to the optimization type hit by the key indicator data, and the memory area optimization operation is performed on the sub-region corresponding to the task according to the memory area optimization strategy.

[0096] In an embodiment of the present application, a memory area optimization operation is performed on the sub-area corresponding to the task according to the memory area optimization strategy, including: if the memory area optimization strategy is memory allocation, the sub-area marked as providing idle memory is located, and the corresponding memory unit is migrated from the idle sub-area to the sub-area corresponding to the task in memory crisis according to the established allocation amount; if the memory area optimization strategy is to shrink the range of the idle sub-area, the boundary of the sub-area in the entire memory layout is adjusted according to a preset shrinkage ratio, and the corresponding memory space is released.

[0097] Specifically, after accurately locking in the sub-regions that meet the optimization conditions, the optimization type is matched based on the key indicator details and a dedicated strategy is formulated. If the "memory allocation" type is hit, the system immediately searches the idle memory "resource pool" to locate those sub-regions with high idle rates and safe memory relocation, and starts an efficient memory transfer process according to the established allocation amount, which can be accurately calculated based on the shortage of emergency sub-regions and the overall memory margin. When transferring, be careful to avoid data blocks that are performing critical tasks, and update the memory mapping table synchronously, so that the newly added memory can seamlessly connect to the emergency sub-region business to ensure data reading and writing continuity; the data integrity is verified throughout the process to prevent transmission errors.

[0098] If the optimization type is "shrink idle sub-area range", call out the preset shrinkage ratio (such as shrinking by 30% of the idle area), carefully adjust the sub-area boundaries, and intelligently determine the data retention plan within the boundary during compression, and migrate scattered useful data to adjacent active sub-areas in an orderly manner to release clean and orderly memory space; during the release process, monitor the memory pressure of surrounding sub-areas in real time to avoid causing memory anomalies in other areas due to a single move; integrate the recovered idle memory, accurately mark it into the resource pool, and wait for a new round of efficient allocation. This cycle repeats itself to ensure that memory allocation always meets the ever-changing needs of the virtual machine business and achieves optimal resource utilization.

[0099] The embodiment of the present application first monitors the key indicator data of the sub-region corresponding to each task in the memory area in real time, and can accurately and timely grasp the dynamic changes of memory usage, just like keeping a close eye on the "pulse" of the system memory. Whether it is the fluctuation of memory occupancy rate, read and write frequency or other key indicators, it can be known at the first time, providing a reliable basis for subsequent decision-making; then analyze these key indicator data to determine whether the sub-region meets the regional optimization conditions, which is equivalent to giving the system a comprehensive "physical examination", accurately identifying those areas with problems such as tight memory resources and idle waste, and preparing optimization measures in a targeted manner. When the optimization conditions are met, the corresponding strategy is obtained and the operation is executed according to the optimization type hit by the key indicator data, which puts the optimization into practice. For example, the memory allocation strategy can cleverly locate idle memory sub-areas and migrate memory units to the sub-areas corresponding to emergency tasks according to reasonable allocation amounts. This is like providing timely help, effectively activating idle resources, alleviating memory pressure on critical tasks, and ensuring smooth operation of important system services. Another example is the strategy of shrinking the scope of idle sub-areas. It scientifically adjusts boundaries and releases space according to preset ratios, making the memory layout more compact and reasonable, avoiding resource waste, and improving the overall utilization of memory resources.

[0100] In an embodiment of the present application, after using the maximum number of memory areas to plan the allocation layout of the memory area of ​​the current virtual machine, the method also includes: detecting whether the layout of the memory area in the current virtual machine has been updated; if the layout of the memory area has been updated, extracting the layout change information corresponding to the memory area; sending the layout change information to the data plane development kit deployed on the opposite device, wherein the data plane development kit is used to determine the changed memory area based on the layout change information, and establish a mapping relationship between the changed memory area and the physical memory address.

[0101] Specifically, during the operation of the virtual machine, a corresponding monitoring mechanism is always in effect to detect whether the layout of the memory area in the current virtual machine has been updated. This monitoring mechanism will compare the key parameters of the memory area at the current moment, such as the range boundaries of each sub-region, the memory start address, the task ownership of the allocated memory, and other information, with the corresponding content recorded at the previous moment. Once a difference is found, it means that the layout of the memory area has been updated.

[0102] When it is determined that the layout of the memory area has been updated, the information extraction process will be started immediately. A special extraction module will accurately extract the corresponding layout change information from the overall data of the memory layout according to the preset rules and format. This information covers details such as which sub-areas have changed, whether the memory has increased or decreased, and whether the memory allocation corresponding to the related tasks has changed.

[0103] Subsequently, relying on the established communication link, the extracted layout change information is sent to the data plane development kit deployed on the peer device. After the peer device receives the layout change information, its internal data plane development kit will immediately start the corresponding processing flow, and accurately determine which memory areas have changed based on the received information through internal parsing and analysis algorithms, and then use its own memory management function to systematically establish new mapping relationships between these changed memory areas and physical memory addresses, so as to ensure that subsequent access, reading and writing operations on these memory areas can accurately correspond to the corresponding physical memory addresses, and ensure that the entire memory management system can still operate stably and efficiently when the layout changes.

[0104] The embodiment of the present application can detect whether the layout of the memory area in the current virtual machine is updated, and can keenly capture changes in the memory architecture level in real time, just like installing an "early warning radar" for memory management, so that the system can know the potential changes in the first time; and when it is detected that the layout is updated, the corresponding layout change information is further extracted, which enables the system to accurately sort out where the changes have occurred, and provide clear "clues" for subsequent targeted processing; then these layout change information are sent to the data plane development kit deployed on the opposite device, and its function is used to determine the changed memory area and establish a mapping relationship with the physical memory address. In this way, no matter whether the memory area is increased, decreased, or adjusted, it can be ensured that it has an accurate correspondence at the physical memory level, thereby ensuring the accuracy and efficiency of memory access, avoiding data read and write errors, system operation jams, and other problems due to changes in memory layout, and overall improving the accuracy, stability, and adaptability of the entire virtual machine system to dynamically changing environments in memory management.

[0105] As an example, Figure 2 As shown:

[0106] ① Initialization of OVS-DPDK.

[0107] Added a DYNAMIC_MEMRGN protocol feature to OVS-DPDK and enabled it by default. Added a query_max_memrgn interface, which returns the maximum number of memory-regions supported by OVS-DPDK (e.g. 64). Added an update_memrgn interface, which is used to add or delete the corresponding memory-region memory mapping.

[0108] ② Initialization of QEMU-KVM side.

[0109] QEMU-KVM initializes the network card, calls the chdev_new operation, then listens to the unix socket, and waits for the OVS-DPDK connection through the listen unix socket operation. This process is implemented through the net_init_vhost_user and vhost_user_start operations, and then executes the wait connect operation.

[0110] ③Connection established.

[0111] OVS-DPDK connects to the unix socket monitored by QEMU-KVM through the connect unix socket operation, detects the connected event on the QEMU-KVM side, and triggers the vhost_user_start operation.

[0112] ④Get characteristics.

[0113] QEMU-KVM calls the OVS-DPDK GET_PROTOCOL_FEATURES interface (via the vhost_user_get_protocol_features operation) to obtain the features enabled by OVS-DPDK and saves them in memory.

[0114] ⑤Query the maximum number of memory-regions.

[0115] QEMU-KVM checks whether the acquired features include the DYNAMIC_MEMRGN feature. If so, QEMU-KVM calls the query_max_memrgn interface of OVS-DPDK (through the vhost_user_query_max_memrgn operation) to dynamically query the maximum number of memory-regions supported by OVS-DPDK. If the DYNAMIC_MEMRGNfeature is not included, the number of memory-regions is set to 8, and the original SET_MTABLE method is used to update up to 8 memory-regions at a time.

[0116] ⑥Memory layout updated.

[0117] When QEMU-KVM needs to update the memory layout, it first compares the current memory layout with the shadow regions to get the memory-region increment. Then it calls the update_memrgn interface of OVS-DPDK (through the vhost_user_update_memrgn operation) to send the memory layout increment (added or deleted memory-region) to OVS-DPDK and save the current memory layout to the shadow regions at the same time.

[0118] After OVS-DPDK receives the memory-region, it processes it through the update_memrgn interface, maps the memory-region that needs to be added, and finds and deletes the memory mapping that needs to be removed.

[0119] Through the above steps, more flexible memory-region management is achieved between QEMU-KVM and OVS-DPDK, breaking through the original limitation of up to 8 memory-regions and optimizing the memory layout update process.

[0120] In this embodiment, a device for allocating a virtual machine memory area is also provided, and the device is used to implement the above-mentioned embodiments and preferred implementation modes, and the descriptions that have been made will not be repeated. As used below, the term "module" can implement a combination of software and / or hardware of a predetermined function. Although the device described in the following embodiments is preferably implemented in software, the implementation of hardware, or a combination of software and hardware, is also possible and conceivable.

[0121] This embodiment provides a device for allocating a virtual machine memory area, such as Figure 3 As shown, including:

[0122] The acquisition module 301 is used to acquire the peer device with which the current virtual machine is to perform docking negotiation, and to acquire the version information of the data plane development kit deployed on the peer device;

[0123] A verification module 302 is used to verify the data plane development kit based on the version information and obtain a verification result;

[0124] The sending module 303 is used to send a query request to the data plane development kit if the data plane development kit passes the verification, wherein the data plane development kit determines the maximum number of memory areas that can be currently carried based on the query request;

[0125] The planning module 304 is used to receive the maximum number of memory areas fed back by the data plane development kit based on the query request, and plan the allocation layout of the memory area of ​​the current virtual machine using the maximum number of memory areas.

[0126] In an embodiment of the present application, the acquisition module 301 is used to search for a peer device that is to be connected and negotiated with the current virtual machine based on a preset communication mechanism; initiate a version acquisition request to the peer device, wherein the peer device feeds back version information of the data plane development kit deployed by the peer device based on the version acquisition request; and receive the version information fed back by the peer device.

[0127] In an embodiment of the present application, the verification module 302 is used to obtain pre-configured dynamic memory area protocol characteristics, wherein the dynamic memory area protocol characteristics include preset version rules for increasing the upper limit of the memory area; match the version information with the preset version rules to obtain a verification result; wherein, if the version information matches the preset version rules, the verification result is a passed verification; or, if the version information matches the preset version rules, the verification result is a failed verification.

[0128] In an embodiment of the present application, the planning module 304 is used to obtain each task running in the current virtual machine and the task characteristics of each task; determine the division priority corresponding to the task based on the task characteristics; obtain a corresponding number of sub-areas from the maximum number of memory areas according to the division priority, and allocate a corresponding number of sub-areas from the memory area of ​​the current virtual machine to the corresponding task.

[0129] In an embodiment of the present application, the device also includes: an analysis module, which is used to monitor in real time the key indicator data of the sub-area corresponding to each task in the memory area; analyze the key indicator data to determine whether the sub-area corresponding to each task meets the regional optimization conditions; if the regional optimization conditions are met, obtain the memory area optimization strategy according to the optimization type hit by the key indicator data, and perform memory area optimization operations on the sub-area corresponding to the task according to the memory area optimization strategy.

[0130] In an embodiment of the present application, the analysis module is used to locate the sub-area marked as providing idle memory if the memory area optimization strategy is memory allocation, and migrate the corresponding memory unit from the idle sub-area to the sub-area corresponding to the memory-critical task according to the established allocation amount; if the memory area optimization strategy is to shrink the range of the idle sub-area, the boundary of the sub-area in the entire memory layout is adjusted according to a preset shrinkage ratio, and the corresponding memory space is released.

[0131] In an embodiment of the present application, the device also includes: a detection module, used to detect whether the layout of the memory area in the current virtual machine is updated; if the layout of the memory area is updated, extracting the layout change information corresponding to the memory area; sending the layout change information to the data plane development kit deployed on the opposite device, wherein the data plane development kit is used to determine the changed memory area based on the layout change information, and establish a mapping relationship between the changed memory area and the physical memory address.

[0132] See also Figure 4 , Figure 4 is a schematic diagram of the structure of an electronic device provided by an optional embodiment of the present invention, such as Figure 4 As shown, the electronic device includes: one or more processors 10, a memory 20, and interfaces for connecting various components, including high-speed interfaces and low-speed interfaces. The various components are connected to each other using different buses for communication, and can be installed on a common mainboard or installed in other ways as needed. The processor can process instructions executed in the electronic device, including instructions stored in or on the memory to display graphical information of the GUI on an external input / output device (such as a display device coupled to the interface). In some optional embodiments, if necessary, multiple processors and / or multiple buses can be used together with multiple memories and multiple memories. Similarly, multiple electronic devices can be connected, and each device provides some necessary operations (for example, as a server array, a group of blade servers, or a multi-processor system).

[0133] The processor 10 may be a central processing unit, a network processor or a combination thereof. The processor 10 may further include a hardware chip. The hardware chip may be a dedicated integrated circuit, a programmable logic device or a combination thereof. The programmable logic device may be a complex programmable logic device, a field programmable gate array, a general purpose array logic or any combination thereof.

[0134] The memory 20 stores instructions executable by at least one processor 10, so that the at least one processor 10 executes the method shown in the above embodiment.

[0135] The memory 20 may include a program storage area and a data storage area, wherein the program storage area may store an operating system, an application required for at least one function; the data storage area may store data created by the use of an electronic device based on the presentation of a small program landing page, etc. In addition, the memory 20 may include a high-speed random access memory, and may also include a non-transient memory, such as at least one disk storage device, a flash memory device, or other non-transient solid-state storage device. In some optional embodiments, the memory 20 may optionally include a memory remotely arranged relative to the processor 10, and these remote memories may be connected to the electronic device via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0136] The memory 20 may include a volatile memory, such as a random access memory; the memory may also include a non-volatile memory, such as a flash memory, a hard disk or a solid state drive; the memory 20 may also include a combination of the above types of memory.

[0137] The electronic device further comprises a communication interface 30 for the electronic device to communicate with other devices or a communication network.

[0138] The embodiment of the present invention also provides a computer-readable storage medium. The method according to the embodiment of the present invention can be implemented in hardware, firmware, or can be implemented as a computer code that can be recorded in a storage medium, or can be implemented as a computer code that is originally stored in a remote storage medium or a non-temporary machine-readable storage medium and will be stored in a local storage medium through a network download, so that the method described herein can be stored in such software processing on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. Among them, the storage medium can be a magnetic disk, an optical disk, a read-only storage memory, a random access memory, a flash memory, a hard disk or a solid-state hard disk, etc.; further, the storage medium can also include a combination of the above types of memories. It can be understood that a computer, a processor, a microprocessor controller, or programmable hardware includes a storage component that can store or receive software or computer code. When the software or computer code is accessed and executed by a computer, a processor, or hardware, the method shown in the above embodiment is implemented.

[0139] Although the embodiments of the present invention have been described in conjunction with the accompanying drawings, those skilled in the art may make various modifications and variations without departing from the spirit and scope of the present invention, and such modifications and variations are all within the scope defined by the appended claims.

Claims

1. A method for allocating a virtual machine memory area, characterized in that: The method comprises: Obtaining a peer device with which the current virtual machine is to perform docking negotiation, and obtaining version information of a data plane development kit deployed on the peer device; Verifying the data plane development kit based on the version information to obtain a verification result; If the verification result is that the verification is passed, a query request is sent to the data plane development kit, wherein the data plane development kit determines the maximum number of memory areas that can be currently carried based on the query request; Receive the maximum number of memory areas fed back by the data plane development kit based on the query request, and use the maximum number of memory areas to plan the allocation layout of the memory areas of the current virtual machine.

2. The method according to claim 1, characterized in that The step of obtaining the peer device for the current virtual machine to be connected and negotiated, and obtaining the version information of the data plane development kit deployed on the peer device, includes: Searching for a peer device for docking and negotiation with the current virtual machine based on a preset communication mechanism; Initiating a version acquisition request to the peer device, wherein the peer device feeds back version information of the data plane development kit deployed by the peer device based on the version acquisition request; Receive the version information fed back by the opposite device.

3. The method according to claim 1, characterized in that The verifying the data plane development kit based on the version information to obtain a verification result includes: Obtaining a pre-configured dynamic memory region protocol characteristic, wherein the dynamic memory region protocol characteristic includes a preset version rule for increasing an upper limit of a memory region; Matching the version information with the preset version rule to obtain the verification result; If the version information matches the preset version rule, the verification result is a passed verification; or, if the version information matches the preset version rule, the verification result is a failed verification.

4. The method according to claim 1, characterized in that: The planning of the allocation layout of the memory area of ​​the current virtual machine by using the maximum number of memory areas includes: Obtaining each task running in the current virtual machine and the task characteristics of each task; Determining a priority level corresponding to the task based on the task characteristics; A corresponding number of sub-regions are obtained from the maximum number of memory regions according to the division priority, and a corresponding number of sub-regions are allocated from the memory region of the current virtual machine to corresponding tasks.

5. The method according to claim 4, characterized in that After allocating a corresponding number of sub-areas from the memory area of ​​the current virtual machine to corresponding tasks, the method further includes: Real-time monitoring of key indicator data of sub-areas corresponding to each task in the memory area; Analyze the key indicator data to determine whether the sub-regions corresponding to each task meet the regional optimization conditions; If the area optimization condition is met, a memory area optimization strategy is obtained according to the optimization type hit by the key indicator data, and a memory area optimization operation is performed on the sub-area corresponding to the task according to the memory area optimization strategy.

6. The method according to claim 5, characterized in that The performing the memory area optimization operation on the sub-area corresponding to the task according to the memory area optimization strategy includes: If the memory area optimization strategy is memory allocation, then locate the sub-area marked as providing idle memory, and migrate the corresponding memory unit from the idle sub-area to the sub-area corresponding to the task in urgent need of memory according to the established allocation amount; If the memory area optimization strategy is to shrink the range of the idle sub-area, the boundary of the sub-area in the entire memory layout is adjusted according to a preset shrinking ratio, and the corresponding memory space is released.

7. The method according to claim 1, characterized in that After planning the allocation layout of the memory area of ​​the current virtual machine by using the maximum number of memory areas, the method further includes: Detecting whether the layout of the memory area in the current virtual machine is updated; If the layout of the memory area is updated, extracting the layout change information corresponding to the memory area; The layout change information is sent to a data plane development kit deployed on the opposite device, wherein the data plane development kit is used to determine the changed memory area based on the layout change information and establish a mapping relationship between the changed memory area and the physical memory address.

8. A device for allocating a virtual machine memory area, characterized in that: The device comprises: An acquisition module is used to acquire a peer device with which the current virtual machine is to perform docking negotiation, and to acquire version information of a data plane development kit deployed on the peer device; A verification module, used to verify the data plane development kit based on the version information to obtain a verification result; A sending module, configured to send a query request to the data plane development kit if the data plane development kit passes the verification, wherein the data plane development kit determines the maximum number of memory areas that can be currently carried based on the query request; A planning module is used to receive the maximum number of memory areas fed back by the data plane development kit based on the query request, and use the maximum number of memory areas to plan the allocation layout of the memory areas of the current virtual machine.

9. An electronic device, characterized in that: include: A memory and a processor, wherein the memory and the processor are communicatively connected to each other, the memory stores computer instructions, and the processor executes the method according to any one of claims 1 to 7 by executing the computer instructions.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer instructions, and the computer instructions are used to enable a computer to execute the method according to any one of claims 1 to 7.

Images