Apparatus and method for managing sharable resources in a multi-core processor

Abstract

Embodiments herein disclose an apparatus and method for managing sharable resources in a multi-core processor. Embodiments herein relate to computer systems, and more specifically, to parallelizing data flow for distributed processing within a computer system. The method includes providing lock-free access to sharable resources in a multi-processing core or a single processing core by releasing assigned sharable resources in a dedicated release sub-queue of each processing core to support cross-core deallocation of sharable resources. The method includes monitoring the occupancy level of each memory pool and dynamically adjusting the allocation of each pool without locking the sharable resources.

Description

Technical Field

[0001] This disclosure relates to computer systems. More specifically, this disclosure relates to parallelizing data streams for distributed processing within a computer system. Background Technology

[0002] Currently, programmable computer systems, including multi-core processor platforms such as Asymmetric Multiprocessing (AMP), Symmetric Multiprocessing (SMP), and Bound Multiprocessing (BMP), may require efficient management of concurrent access to shared resources. Typically, an operating system (OS) or real-time operating system (RTOS) provides inter-processor communication (IPC) methods. Furthermore, OS / RTOS can provide cross-core resource locking methods (such as spinlocks) and intra-core thread resource locking methods (such as semaphores and int-locks) to prevent concurrent access to shared resources (such as peripheral ports and memory). Additionally, dynamic resource management for multi-core processors may require handling metadata (such as resource availability information), where metadata can be shared resources. Conventional methods handle shared resources through locking (such as int-locks, semaphores, and spinlocks). However, conventional locking methods can impact performance. Frequent resource locking and waiting to unlock can affect parallelism in multi-core systems / processors. Furthermore, cores / threads may not fully utilize dedicated memory, thus wasting available memory.

[0003] Therefore, refer to the following: Figures 1a to 3b This describes conventional methods for accessing shared resources in single-core and multi-core processors, based on existing technologies.

[0004] Figure 1a This diagram illustrates a typical single-core processor accessing shared resources. A single processor core can have multiple threads that will be run. Furthermore, a single data memory pool and a single metadata file are allocated for the single-core processor's running threads. Additionally, memory allocation and deallocation performed by the processor may require in-core locks (i.e., interrupt locks) to protect critical sections (such as the metadata file). The metadata file can be protected across multiple threads.

[0005] Figure 1b and Figure 1c It is a flowchart depicting the conventional method of accessing shared resources by a single-core processor.

[0006] Memory allocation / deallocation may require both intra-core locks (i.e., interrupt locks) and inter-core locks (i.e., spinlocks) to protect critical sections (such as metadata). During the intra-core lock acquisition step, the processor can disable interrupts and may not allow another thread to run. During the intra-core lock release step... Figure 1c As shown in the diagram, the processor can allow waiting threads to resume and restart from the kernel lock acquisition step. The step marked "A" can be a critical section. Within a critical section, the processor can allow one thread at a time, and other threads may need to wait during the kernel lock acquisition step.

[0007] Figure 2a This diagram illustrates how a typical multi-core processor accesses shared resources.

[0008] A multi-core processor with each core can have multiple threads to run. A multi-core processor may be allocated a single pool of data memory and a single metadata file to run multiple threads. Furthermore, memory allocation and deallocation may require inter-core locks (i.e., spinlocks) and intra-core locks (i.e., interrupt locks) to protect critical sections (such as the metadata file). Locks can affect parallelism in a multi-core processor.

[0009] Figure 2b This diagram illustrates how a typical multi-core processor accesses shareable resources in a dedicated metadata file for each core of the processor.

[0010] Metadata files can be allocated for each core of the processor. Furthermore, each thread can apply an intra-core lock when accessing a dedicated metadata file. However, inter-core locks may be needed to protect the metadata during the deallocation or release of critical sections such as metadata files.

[0011] Figure 2c This diagram illustrates a typical multi-core processor based on cross-core release access to shared resources.

[0012] In a cross-core deallocation scenario, core-0 can allocate one memory block from memory pool-0 associated with core-0. Information about the allocated memory block can be updated by core-0 to the metadata-0 file associated with core-0. Furthermore, core-0 can share the memory block data with core-1. However, during deallocation or release of critical sections (such as metadata files), inter-core locks may be needed to protect the metadata.

[0013] Figure 2d This diagram illustrates a typical multi-core processor accessing the same metadata block to allocate memory blocks.

[0014] In a cross-core release scenario, core-1 can release block-0, which is shared with core-0, to the metadata-0 block. Simultaneously, core-0 can attempt to allocate another block to another core by accessing the metadata-0 file / block. However, metadata-0 can still be a public / shared resource and a critical section. Therefore, inter-core locking (i.e., spinlocks) may not be unavoidable.

[0015] Figure 3a and Figure 3bThis is a flowchart depicting a conventional method for allocation and deallocation using a multi-core processor. To access busy and free lists while releasing pointers belonging to different cores, the conventional method may need to protect critical section metadata, thus dedicating resources to these critical sections, which could be detrimental to parallel implementation in a multi-core system. In the critical section marked "B" ( Figure 3a and Figure 3b In the diagram, thread _1 in core-0 can acquire both the core lock and the spinlock. Therefore, other threads in core-0 may need to wait for the core lock to be released. Furthermore, cores-1,-2, and-3 may need to wait for the spinlock to be released.

[0016] In conventional approaches, dynamic memory management solutions use per-core / per-thread static resource (memory) allocation to process incoming and release data stream blocks. Therefore, allocations made by the processor can use static allocation, and resources (memory) are released by the same core / thread. However, if resources allocated by a particular core are deallocated / released by other cores, access to shared / shared resources may result in access conflicts.

[0017] However, conventional methods do not allow memory / buffers to be allocated from one core / thread and released from another. In the context of multi-threaded / multi-core systems, conventional methods do not allow for dynamic buffer access and release. Summary of the Invention

[0018] Technical issues

[0019] This disclosure has been made to at least address the aforementioned problems and / or disadvantages and to at least provide the advantages described below. Therefore, one aspect of this disclosure is to provide an apparatus and method for managing shareable resources associated with a multi-core processor in a computing environment.

[0020] Another aspect of this disclosure is to provide devices and methods for resource management in a multi-core processor by having a dedicated resource pool and metadata per core / thread.

[0021] Another aspect of this disclosure is to provide an apparatus and method for cross-core deallocation of resources using a dedicated release queue management having an exclusive set of subqueues.

[0022] Another aspect of this disclosure is to provide an apparatus and method for monitoring the occupancy level of each memory pool and dynamically adjusting the allocation of each pool in a lock-free manner.

[0023] Technical solution

[0024] Therefore, embodiments of this document provide a method for managing shareable resources in a multi-core processor. The method includes: a target processing core accessing a shareable resource associated with a source processing core. The source processing core and the target processing core reside in the multi-core processor. The method includes: the source processing core generating, based on the accessed shareable resource, a plurality of release sub-queues corresponding to each of at least one target processing core in a release queue of the source processing core, to release the shareable resource assigned by the source processing core to the target processing core. The method includes: based on analyzing first information associated with the shareable resource, the target processing core releasing at least one accessed shareable resource to the plurality of release sub-queues generated in the release queue of the source processing core. The first information associated with the shareable resource is stored in a metadata file. The method includes: the source processing core updating second information in the stored metadata file corresponding to the source processing core based on identifying the release of the shareable resource in the release queue.

[0025] Therefore, embodiments of this document provide a device for managing shareable resources in a multi-core processor. The device is configured to allow a target processing core to access a shareable resource associated with a source processing core. The device is configured to: generate, based on the accessed shareable resource, a plurality of release sub-queues corresponding to each of at least one target processing core in a release queue of the source processing core, to release the shareable resource assigned by the source processing core to the target processing core. The device is configured to: release at least one accessed shareable resource to the generated plurality of release sub-queues in the release queue of the source processing core based on analysis of first information associated with the shareable resource, wherein the first information associated with the shareable resource is stored in a metadata file. The device is configured to: update second information in the stored metadata file corresponding to the source processing core based on identifying the release of the shareable resource in the release queue.

[0026] These and other aspects of the exemplary embodiments herein will be better appreciated and understood when considered in conjunction with the following description and accompanying drawings. However, it should be understood that the following description is given by way of illustration rather than limitation, indicating exemplary embodiments and their many specific details. Many changes and modifications may be made within the scope of the exemplary embodiments herein without departing from the spirit of this document, and the exemplary embodiments herein encompass all such modifications. Attached Figure Description

[0027] The above and other aspects, features, and advantages of specific embodiments of the present disclosure will become more apparent from the following detailed description taken in conjunction with the accompanying drawings, in which:

[0028] Figure 1a This diagram illustrates a typical single-core processor accessing shared resources.

[0029] Figure 1b and Figure 1c It is a flowchart depicting the conventional method of accessing shared resources by a single-core processor;

[0030] Figure 2a This diagram illustrates a typical multi-core processor accessing shared resources.

[0031] Figure 2b This diagram illustrates how a typical multi-core processor accesses shareable resources in a dedicated metadata file for each core of the processor.

[0032] Figure 2c This diagram illustrates a conventional multi-core processor based on cross-core release access to shared resources.

[0033] Figure 2d A block diagram is shown illustrating how a typical multi-core processor accesses the same metadata block to allocate memory blocks;

[0034] Figure 3a and Figure 3b It is a flowchart depicting the conventional methods used for allocation and release by a multi-core processor;

[0035] Figure 4 An apparatus for managing shareable resources in a computing environment in a multi-core processor is shown according to embodiments of the present disclosure;

[0036] Figure 5a A block diagram is shown illustrating an embodiment of the present disclosure for managing shareable resources using a single release queue for each core of a multi-core processor;

[0037] Figure 5b A block diagram is shown illustrating an embodiment of the present disclosure for managing shareable resources using multiple release subqueues for each core of a multi-core processor;

[0038] Figure 6a This is a flowchart depicting a method for adding a pointer to a release queue according to an embodiment of the present disclosure;

[0039] Figure 6b This is a flowchart depicting a method for releasing a pointer in a release queue according to an embodiment of the present disclosure;

[0040] Figure 7a This is a flowchart depicting a method for cross-core allocation using a dedicated resource pool per core and / or per thread, according to embodiments of the present disclosure;

[0041] Figure 7b This is a flowchart depicting a method for cross-core release using a dedicated release queue per core and / or per thread, according to embodiments of the present disclosure;

[0042] Figure 8a This is a flowchart depicting a method for dynamic pool adjustment according to embodiments of the present disclosure;

[0043] Figure 8b This is a flowchart depicting steps for dynamic pool adjustment according to embodiments disclosed herein;

[0044] Figure 9a This is a flowchart depicting a method for managing associated shareable resources in a multi-core processor according to embodiments of the present disclosure;

[0045] Figure 9b This is a flowchart depicting a method according to embodiments of the present disclosure for determining whether at least one shareable resource being accessed corresponds to a source processing core;

[0046] Figure 9c This is a flowchart depicting a method, according to embodiments of the present disclosure, for pushing shareable resources of a source processing core to a release subqueue marked in a free list during dynamic pooling; and

[0047] Figure 9d This is a flowchart depicting a method for updating a metadata file corresponding to a source processing core by a source processing core according to embodiments of the present disclosure.

[0048] Throughout the accompanying drawings, the same reference numerals will be understood to refer to the same parts, components, and structures. Detailed Implementation

[0049] The exemplary embodiments herein, along with their various features and advantageous details, are explained more fully with reference to the non-limiting embodiments illustrated in the accompanying drawings and detailed in the following description. Descriptions of well-known components and processing techniques have been omitted to avoid unnecessarily obscuring the embodiments herein. The description herein is intended only to aid in understanding how the exemplary embodiments herein may be practiced, and further to enable those skilled in the art to practice the exemplary embodiments herein. Therefore, this disclosure should not be construed as limiting the scope of the exemplary embodiments herein.

[0050] The embodiments described herein implement an apparatus and method for managing shareable resources in a multi-core processor by generating dedicated release subqueues. Referring now to the accompanying drawings, and more specifically to… Figures 4 to 9d , among which, Figures 4 to 9d In the diagrams of the illustrated example embodiments, similar reference characters consistently represent the corresponding features.

[0051] Figure 4 A device 100 for managing shareable resources in a multi-core processor 102 is shown according to an embodiment of the present disclosure.

[0052] Device 100 may be at least one of, but is not limited to, servers, desktop computers, handheld devices, multiprocessor systems, microprocessor-based programmable consumer electronics, laptops, network computers, minicomputers, mainframe computers, modems, vehicle infotainment systems, and consumer electronics. Device 100 may include a multi-core processor 102 and memory 104. Memory 104 may be at least one of, but is not limited to, static memory, dynamic memory, flash memory, cache memory, and random access memory (RAM).

[0053] Processor 102 or multi-core processor 102 may include multiple cores, such as source processing core 102a and at least one target processing core 102b. Source processing core 102a may be at least one of core 0, core 1, core 2, core 3, etc. Target processing cores may be at least two of core 0, core 1, core 2, core 3, etc. Source processing core 102a may assign a dedicated memory block to each core of multi-core processor 102. Memory 104 may include at least one shareable resource, such as, but not limited to, metadata, data streams, packets, etc. Furthermore, device 100 may include release pointers stored in static memory or static arrays. Release pointers may have one or more release queues dedicated to each core of multi-core processor 102. Release queues may also have dedicated release subqueues, such as an entry queue for each core of processor 102 or multi-core processor 102.

[0054] In addition, the device may include input interfaces (not shown) and output interfaces (not shown) connected via a bus (not shown), wherein the bus may represent one or more system buses and / or peripheral buses. The data source for device 100 and multi-core processor 102 may be, but is not limited to, at least one of packetized data from applications, databases, computer networks, scientific instruments, real-time video capture devices, etc. Device 100 may also include volatile and / or non-volatile memory (not shown), removable and / or non-removable media, processor-readable instructions, data structures, program modules, other data, etc. Volatile and / or non-volatile memory includes at least one of the following: random access memory (RAM), read-only memory (ROM), EEPROM, flash memory, CD-ROM, digital universal disk or other optical storage, magnetic tape, magnetic tape, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and is accessible by source processing core 102a and / or at least one target processing core 102b.

[0055] Flash memory or other forms of fixed or removable storage media in device 100 can be used to store desired programmable instructions and program data, and can be accessed by cores such as source processing core 102a and at least one target processing core 102b. Furthermore, the operating system (OS) / real-time operating system (RTOS) of device 100 allows the partitioning of the physical address space of memory 104 to manage shareable resources. Memory 104 can permit multiple concurrent read / write operations.

[0056] The operating system (OS) / real-time operating system (RTOS) may include at least one of the submodules such as, but not limited to, a kernel processing module, a thread management module, a process management module, an input / output (“I / O”) management module, and a memory management module. The process management module can perform multitasking for OS access to the cores of the multi-core processor 102 by initializing, scheduling, and switching processes. The thread management module manages the instantiation and execution of application threads, including receive threads and send threads of the multi-core processor 102. For example, the thread management module can allocate threads for execution among the cores of the multi-core processor 102. The memory management module controls the allocation, use, and deallocation of the physical address space provided by the memory 104.

[0057] Advantageously, at least one aspect of the embodiments herein enables the dynamic reallocation of shareable resources across logical partitions under the guidance of a workload manager (not shown). Shared resources may include, but are not limited to, at least one of, CPU (Central Processing Unit) resources, logical processor resources, input / output resources, coprocessor resources, channel resources, network adapters, memory resources, audio, displays, common peripherals, serial ports, parallel ports, etc. In the example, during the execution of a task, the memory management module may typically allocate a stack and a heap for allocating memory blocks. The allocated memory blocks may be referenced by pointers.

[0058] Device 100 can process incoming data received from the input interface and can parallelize the incoming data. The input interface can be at least one of a network interface card (NIC), a programmable NIC, an analog-to-digital converter (not shown), etc., coupled to the multi-core processor 102. Device 100 may have a buffer mapped to memory 104, wherein the buffer can be used to store intermediate data.

[0059] like Figure 4The lengths of the memory blocks 103a-103d shown are variable. Memory blocks 103a-103d may include Ethernet datagrams, Internet Protocol packets, Asynchronous Transfer Mode (ATM) cells, data constituting the operation of a scientific instrument, video frames or video-coded blocks, images, blocks of instrument data, etc. Furthermore, threads may be split among the cores of the multi-core processor 102 during operation. Each thread or memory block may include similar components that operate similarly. Each core of the multi-core processor 102 may also have a different number of buffers and transmit threads. Memory 104 may also include metadata dedicated to each core of the multi-core processor 102. In this example, the metadata may include references to threads, references to pointers, references to locations in memory 104, the length of the memory blocks, etc.

[0060] In one embodiment, device 100 is configured to assign at least one shareable resource stored in memory 104 to at least one target processing core 102b based on the type of task determined to be run by multi-core processor 102. In another embodiment, at least one shareable resource is assigned by source processing core 102a. In another embodiment, device 100 is configured to store information associated with the assigned at least one shareable resource in a metadata file corresponding to source processing core 102a. In another embodiment, device 100 is configured to allow target processing core 102b to access the shareable resource associated with source processing core 102a. In another embodiment, device 100 is configured to provide at least one target processing core 102b with access to the assigned at least one shareable resource based on information stored in the metadata file. In another embodiment, device 100 is configured to determine whether the at least one shared resource accessed corresponds to source processing core 102a based on the stored metadata file. In another embodiment, at least one target processing core 102b determines the at least one shareable resource accessed based on access to the at least one shareable resource. In one embodiment, device 100 is configured to generate multiple release sub-queues corresponding to each of at least one target processing core 102b in the release queue of source processing core 102a to release shareable resources assigned by source processing core 102a to target processing core 102b. In another embodiment, device 100 is configured to release at least one accessed shareable resource to the generated multiple release sub-queues in the release queue of source processing core 102a based on analyzed first information associated with the shareable resource. In another embodiment, the first information associated with the shareable resource is stored in a metadata file. Pointers may be stored in the release sub-queues. The multi-core processor 102 can access the pointers via an indirect addressing mode instruction set. In another embodiment, the shareable resource is released by target processing core 102b. In another embodiment, device 100 is configured to identify whether the accessed shareable resource is released by at least one target processing core 102b based on analysis of the release queues corresponding to source processing core 102a and at least one target processing core 102b. In an embodiment, device 100 is configured to update second information in a stored metadata file corresponding to source processing core 102a based on the recognition of the release of a shareable resource in the release queue.

[0061] In one embodiment, device 100 is configured to determine the available space of each release subqueue in the release queue. In another embodiment, device 100 is configured to determine whether the available space of each release subqueue is higher or lower than a predefined threshold. In another embodiment, device 100 is configured to update information corresponding to the free list and busy list of the available space of each release subqueue in the metadata file corresponding to the source processing core 102a and at least one target processing core 102b, based on the updated metadata file. In another embodiment, device 100 is configured to: if the available space of each release subqueue is determined to be lower than the predefined threshold, set an insufficient flag corresponding to the source processing core 102a and at least one target processing core 102b based on the updated metadata file. In yet another embodiment, device 100 is configured to: if the available space of a release subqueue is determined to be lower than the predefined threshold, push the shareable resources of the source processing core 102a to the release subqueue marked in the free list by dynamically adjusting the pool size of the release queue. In one embodiment, device 100 is configured to trigger the release of a shared resource during the assignment of the shared resource if the release queue corresponding to the source processing core 102a has available space. In another embodiment, device 100 is configured to facilitate the release of a shared resource during the release of the shared resource to the release queue if the release queue corresponding to the source processing core has available space. In yet another embodiment, device 100 is configured to parse a metadata file to determine at least one of a pool ID, a free list of pool IDs, a busy list of pool IDs, and an assigned shared resource ID. The pool ID may be the core ID / core number of a respective memory pool. For example, the pool ID corresponding to core 2 of the memory pool is 2. In yet another embodiment, information associated with the shared resource includes the pool ID, the assigned shared resource ID, the resource block ID, and the assigned core ID.

[0062] In an embodiment, the source processing core 102a and at least one target processing core 102b include at least one of core 0, core 1, core 2, core 3, etc. In an embodiment, assigning at least one shareable resource includes allocating a memory block in memory 104 to each of the source processing core 102a and the target processing core 102b to access the shareable resource in the memory block. In an embodiment, a metadata file is generated for each of the source processing core 102a and the target processing core 102b, and the metadata file is stored sequentially according to the order of each processing core. In an embodiment, the release queue corresponding to the source processing core 102a includes at least one entry queue corresponding to at least one target processing core 102b. In an embodiment, the step of releasing at least one shareable resource includes updating at least one entry queue corresponding to at least one target processing core 102b. In an embodiment, the shareable resource is assigned by the source processing core 102a and released by at least one target processing core 102b.

[0063] Figure 4 The functional components of a computer-implemented system are illustrated. In some cases, components may be hardware components, software components, or a combination of hardware and software. Some components may be application-level software, while others may be operating system-level components. In some cases, the connection from one component to another may be a tight connection, where two or more components operate on a single hardware platform. In other cases, connection may be achieved via a network connection spanning long distances. Each embodiment may use different hardware, software, and interconnect architectures to implement the described functionality.

[0064] The embodiments described herein may include hardware and software elements. Software-implemented embodiments include, but are not limited to, firmware, resident software, microcode, etc. The functions performed by the various modules described herein may be implemented in other modules or combinations of other modules. For the purposes of this description, a computer-usable or computer-readable medium may be any device that may include, store, communicate, propagate, or transmit programs for use by or in conjunction with an instruction execution system, device, or apparatus.

[0065] Figure 5a A block diagram is shown illustrating an embodiment of the present disclosure for managing shareable resources using a single release queue for each core of a multi-core processor 102.

[0066] Consider a cross-core release scenario where core-1 can release resource block 0, shared by core-0, from memory 104 to the core-0 release queue. Simultaneously, core-0 can allocate / assign another resource block when accessing metadata-0 without any conflicts. In this scenario, the processors are mapped to four release pointer queues for the four cores. Pointers can be added or generated in the release queues. For example, the release queues could be shared resources for the cores of a multi-core processor 102. The release queues can be accessed concurrently by multiple cores. Critical sections, such as the release queues, can be protected.

[0067] Figure 5b A block diagram is shown illustrating an embodiment of the present disclosure for managing shareable resources using multiple release subqueues for each core of a multi-core processor 102.

[0068] In this embodiment, multiple release sub-queues corresponding to each of at least one target processing core 102b are generated in the release queue corresponding to the source processing core 102a to release the identified shareable resource corresponding to the source processing core 102a. An exclusive release sub-queue for each processing core is added to a pointer. In this embodiment, based on information parsed from a metadata file, at least one accessed shareable resource is released to multiple release sub-queues in the release queue corresponding to the source processing core 102a. The shareable resource is then released by the target processing core 102b.

[0069] The embodiments described herein provide an Exclusive Release Queue (ERQ) for each core, and ERQs can be added on a per-thread-run basis in the case of a single-core processor. Shared resources are added to the entry queue of release pointers to avoid locking the shared resources.

[0070] Figure 6a This is a flowchart depicting a method for adding a pointer to a release queue according to an embodiment of the present disclosure.

[0071] The pointer in the release queue can be added by the multi-core processor 102. In step 611, the target processing core 102b determines whether the release queue / release pointer does not belong to the target processing core 102b. And, if the release queue / release pointer does not belong to the target processing core 102b, then in step 613, the target processing core 102b can release the pointer to the release queue of the source processing core 102a. The release queues of each core can be updated using shared resources based on information stored in the metadata files of each core.

[0072] Figure 6b This is a flowchart depicting a method for releasing a pointer in a release queue according to an embodiment of the present disclosure.

[0073] In the example, the shareable resource assigned by core 0 can be released to the release subqueue of the release queue / release pointer. In step 621, the target processing core 102b (such as core 1, core 2, and core 3) determines whether the release queue / release pointer is empty and whether there is available space. If the release queue has empty space, then in step 623, the target processing core 102b can invoke a release operation to release the shareable resource and add it to the release subqueue / entry queue of the release queue / release pointer.

[0074] Figure 7a This is a flowchart depicting a method for cross-core allocation using a dedicated resource pool per core and / or per thread, according to embodiments of the present disclosure.

[0075] In the example, to allocate / assign a memory block by the source processing core 102a, in steps 703 and 705, the multi-core processor 102 can acquire an intra-core lock and obtain the core ID from the stored metadata files of each processing core. In step 707, the multi-core processor 102 determines whether the release pointer corresponding to the target processing core 102b is not null. If the release pointer corresponding to the target processing core 102b is not null, then in step 709, the free list of release pointers can be determined by parsing the metadata of each processing core. Furthermore, in step 711, memory blocks can be analyzed to determine allocated and free memory blocks. If memory blocks are available, then in step 713, the free memory blocks and busy memory blocks can be updated in the list and stored in the metadata files of each processing core. In step 715, the acquired intra-core lock can be released after the task is run. Then, in step 717, the address of the memory block can be returned.

[0076] Additionally, if the memory block is unavailable, the acquired kernel lock can be released and NULL can be returned in steps 719 and 721.

[0077] In the example, consider a hot management scenario where dynamic memory can be allocated and deallocated. Furthermore, threads or processing cores can request memory allocation corresponding to data relevant to hot management. Dynamic memory can allocate memory, and details of the amount of memory allocated can be stored as metadata files for each processing core's memory. Therefore, the metadata can, for example, be a public / shareable resource.

[0078] In the example, consider pipelined operation (i.e., cross-core release of the packet buffer in the modem). Packet processing can be performed in four stages, such as...

[0079] Phase 1: MAC Processing

[0080] Phase 2: RLC processing

[0081] Phase 3: PDCP processing

[0082] Phase 4: Applying Packet Routing

[0083] In a parallel execution design with decomposed functionality, such as a quad-core processor, each stage can run on a separate core. Packet buffers allocated by the MAC processing core will be released by another core (e.g., the application packet routing core). In parallel execution with decomposed functionality, the shared resource is the heap manager's metadata, which may be needed to allocate memory each time a new packet arrives.

[0084] In another example, consider load balancing in a symmetric multiprocessing (SMP) system. Therefore, a multi-core SMP operating system could have a ready queue and a wait queue for each thread on each core. During dynamic load balancing performed by the scheduler, the ready queue and wait queue are accessed across cores. In a Linux SMP multi-core scheduler, processors push threads from busy cores to the ready queues of idle cores. In a load-balanced SMP system, shared resources can be, but are not limited to, at least one of the following: heap manager metadata that may be needed to allocate memory; and operating system (OS) metadata or task control blocks (i.e., accessed concurrently from different cores by the OS scheduler for load balancing).

[0085] Figure 7b This is a flowchart depicting a method for cross-core release using a dedicated release queue per core and / or per thread, according to embodiments of the present disclosure.

[0086] In the example, to release the allocated memory block by the source processing core 102a, in steps 723 and 725, the multi-core processor 102 can acquire an in-core lock and obtain the core ID from the stored metadata file of each processing core. In step 727, the multi-core processor 102 determines whether the release pointer corresponding to the target processing core 102b is not null. If the release pointer corresponding to the target processing core 102b is not null, then in step 729, the free list of the release pointer can be determined by parsing the metadata of each processing core. If the release pointer is null, the pointer can be invoked by the target processing core 102b. Then, in step 731, the target processing core 102b can determine whether the pointer or the shared resource belongs to the core ID. If the pointer or the shared resource belongs to the core ID, then in steps 733 and 735, the metadata can be parsed to determine the busy list, and the busy list and the free list can be updated in the metadata. And, in step 737, the acquired in-core lock can be released after the task is run.

[0087] Additionally, if the pointer or shared resource does not belong to the kernel ID, the release queue can be updated in step 739.

[0088] Figure 8a This is a flowchart depicting a method for dynamic pool adjustment according to embodiments of the present disclosure.

[0089] Reference Figure 8a As shown in (a), in order for a memory block to be allocated / assigned by the source processing core 102a, in steps 803 and 805, the multi-core processor 102 can acquire an in-core lock and obtain the core ID from the stored metadata file of each processing core. In step 807, the multi-core processor 102 releases the pointers in the release pointer queue.

[0090] In step 809, the multi-core processor 102 adjusts the dynamic pool size. In this example, dynamic realignment of the resource pool size, dedicated to each core / thread, can be performed based on monitoring the occupancy level of each pool during runtime. Furthermore, due to the exclusive child release queue, the resource pool size can be dynamically adjusted for each core in an efficient and lock-free manner. Adjusting the dynamic pool size for each core has the advantage of optimizing the use of the overall resource pool size. Additionally, resources may not remain unused for extended periods.

[0091] In step 811, memory blocks can be analyzed to determine allocated and free memory blocks. If memory blocks are available, in step 813, the list of free and busy memory blocks can be updated and stored in the metadata file of each processing core. In step 815, the acquired core lock can be released after the task is run. Then, in step 817, the address of the memory block can be returned.

[0092] Additionally, if the memory block is unavailable, the acquired kernel lock can be released and NULL can be returned in steps 819 and 821.

[0093] Reference Figure 8a As shown in (b), steps 823 to 829 perform the same operations as steps 803 to 809. And steps 831 to 839 perform the same operations as steps 731 to 738. Therefore, a detailed description will be omitted here.

[0094] Figure 8b This is a flowchart depicting the steps for dynamic pool adjustment according to embodiments of the present disclosure.

[0095] In the example, in step 871, the multi-core processor 102 determines the available space of each release subqueue in the release queue and analyzes whether the available space of each release subqueue is higher or lower than a threshold. Information corresponding to the analyzed available space of each release subqueue can be updated in the metadata files corresponding to the source processing core 102a and at least one target processing core 102b. In other words, if the available space of each release subqueue is higher or lower than the threshold, in step 875, the multi-core processor 102 sets an insufficient flag and a sufficient flag for adjusting the pool size. Alternatively, if the available space of each release subqueue is neither higher nor lower than the threshold, in step 873, the multi-core processor 102 removes the insufficient flag and the sufficient flag for the current core.

[0096] Furthermore, if the source processing core 102a and at least one target processing core 102b may need to allocate or release resources (memory blocks), then as Figure 8bAs shown in the diagram, source processing core 102a and at least one target processing core 102b can check the insufficient or sufficient flag of each core based on a lower threshold and an upper threshold. During runtime, source processing core 102a and at least one target processing core 102b may need to allocate or release resources, and then in step 877, source processing core 102a and at least one target processing core 102b can check whether the current state is sufficient. If the current state is sufficient, then in step 879, each processing core can facilitate other insufficient cores by initially changing the ownership of the memory block to the insufficient core. Furthermore, in steps 881 and 883, each processing core can write a pointer to the entry block of the sufficient core in the memory block of the exclusive sub-release queue corresponding to the insufficient core. Figure 8a As shown, it may be necessary to maintain the switch guard space to avoid frequent conflicts between any cores corresponding to insufficient and sufficient states.

[0097] Figure 9a This is a flowchart depicting a method 900a for managing shareable resources in a multi-core processor 102 according to embodiments of the present disclosure.

[0098] In step 902, method 900a includes: the target processing core 102b accessing a shareable resource associated with the source processing core 102a. In step 904, method 900a includes: the source processing core 102a generating multiple release sub-queues corresponding to each of at least one target processing core 102b in its release queue based on the accessed shareable resource, to release the shareable resource assigned by the source processing core 102a to the target processing core 102b. In step 906, method 900a includes: the target processing core 102b releasing at least one accessed shareable resource to the generated multiple release sub-queues in the release queue of the source processing core 102a based on analyzing first information related to the shareable resource, wherein the first information related to the shareable resource is stored in a metadata file. In step 908, method 900a includes: the source processing core 102a updating second information in the stored metadata file corresponding to the source processing core 102a based on recognizing the release of the shareable resource in the release queue.

[0099] The various actions in method 900a can be performed in the order they are presented, in different orders, or simultaneously. Furthermore, in some embodiments, actions may be omitted. Figure 9a Some of the actions listed in the document.

[0100] Figure 9b This is a flowchart depicting a method 900b according to an embodiment of the present disclosure for determining whether an accessed at least one shareable resource corresponds to a source processing core 102a.

[0101] In step 912, method 900b includes: assigning at least one shareable resource stored in memory 104 to at least one target processing core 102b based on a determined type of task to be run by the multi-core processor 102. In step 914, method 900b includes: storing first information associated with the assigned at least one shareable resource in a metadata file corresponding to the source processing core 102a. In step 916, method 900b includes: providing access to the assigned at least one shareable resource to at least one target processing core 102b based on the information stored in the metadata file. In step 918, method 900b includes: determining whether the at least one shareable resource to be accessed corresponds to the source processing core 102a based on the stored metadata file. In an embodiment, at least one target processing core 102b determines the at least one shareable resource to be accessed based on accessing at least one shareable resource.

[0102] The various actions in method 900b can be performed in the order they are presented, in different orders, or simultaneously. Furthermore, in some embodiments, actions may be omitted. Figure 9b Some of the actions listed in the document.

[0103] Figure 9c This is a flowchart depicting a method 900c for pushing shareable resources of source processing core 102a to a release subqueue marked in a free list during dynamic pool adjustment, according to embodiments of the present disclosure.

[0104] In step 922, method 900c includes: determining the available space of each release subqueue in the release queue by the multi-core processor 102. In step 924, method 900c includes: determining whether the available space of each release subqueue is higher or lower than a predefined threshold by the multi-core processor 102. In step 926, method 900c includes: updating information corresponding to the free list and busy list of available space for each release subqueue in the metadata file corresponding to the source processing core 102a and at least one target processing core 102b, and the analyzed information. In step 928, method 900c includes: if the available space of each release subqueue is lower than the predefined threshold, setting an insufficient flag corresponding to the source processing core 102a and at least one target processing core 102b based on the updated metadata file. In step 930, method 900c includes: if the available space of the release subqueue is lower than a threshold, the multi-core processor 102 pushes the shareable resources of the source processing core 102a to the release subqueue marked in the free list by dynamically adjusting the pool size of the release queue.

[0105] The various actions in method 900c can be performed in the order they are presented, in different orders, or simultaneously. Furthermore, in some embodiments, actions may be omitted. Figure 9c Some of the actions listed in the document.

[0106] Figure 9d This is a flowchart of a method 900f for updating a metadata file corresponding to a source processing core 102a according to an embodiment of the present disclosure.

[0107] In step 932, method 900f includes: allocating a shareable resource from memory 104 to at least one target processing core 102b by source processing core 102a. In step 934, method 900f includes: updating information related to the shareable resource in a metadata file corresponding to source processing core 102a by source processing core 102a. In step 936, method 900f includes: accessing the allocated shareable resource from memory 104 by target processing core 102b. In step 938, method 900f includes: determining the shareable resource allocated by source processing core 102a by target processing core 102b. In step 940, method 900f includes: releasing the shareable resource allocated by source processing core 102a by target processing core 102b, wherein the step of releasing the shareable resource includes updating the release queue corresponding to source processing core 102a. In step 942, method 900f includes: identifying, by source processing core 102a, the release of the shareable resource by target processing core 102b based on checking the release queue corresponding to source processing core 102a. In step 944, method 900f includes: updating the metadata file corresponding to source processing core 102a by source processing core 102a. In an embodiment, the release queue corresponding to source processing core 102a includes at least one ingress queue corresponding to at least one target processing core 102b. In an embodiment, the step of updating the release queue corresponding to source processing core 102a further includes updating at least one ingress queue corresponding to at least one target processing core 102b.

[0108] The various actions in method 900f can be performed in the order they are presented, in different orders, or simultaneously. Furthermore, in some embodiments, actions may be omitted. Figure 9d Some of the actions listed in the document.

[0109] In the example, the maximum possible gain can be obtained according to the embodiments described in this article. Example test code (i.e., pseudocode) based on experimental testing can be as follows:

[0110] Set Num_Iterations = 1000000

[0111] Start Timer

[0112] Repeat for Num_Iterations:

[0113] mem = Allocate(1000)

[0114] Release(mem)

[0115] Stop Timer and calculate running time

[0116] In another example, the testing steps can be as follows:

[0117] Create a task for each core that runs the test code above. Run the task in DUT#1 (with spinlocks) and DUT#2 (the proposed scheme).

[0118] Measure the runtime of tasks in each core.

[0119] Test results may include calculating the gain of device under test (DUT) #2 relative to DUT #1.

[0120]

[0121] Therefore, the test results show high gain. The embodiments in this paper enable multi-core parallelism and free calls are made from different cores. The second test attempts to observe the gain at different frequencies of allocation and free calls.

[0122] In the example, the test code (i.e., pseudocode) used for the second test could be as follows:

[0123] Set Num_Iterations = 1000000

[0124] Set Num_wait = <variable>

[0125] Start Timer

[0126] Repeat for Num_Iterations:

[0127] mem = Allocate(1000)

[0128] wait for Num_wait instructions

[0129] Release(mem)

[0130] Stop Timer and calculate running time

[0131] The testing process for the second test can be as follows:

[0132] Create a task for each core that runs the test code above.

[0133] Run the task in DUT#1 (with spinlock) and DUT#2 (the proposed scheme).

[0134] Measure the runtime of the tasks in each core, as calculated in Test #1.

[0135] Based on the frequency analysis gain (%) of requests per 1M instructions, the system performance gradually decreases as the number of allocation / release calls per second decreases.

[0136] The embodiments described herein allow for the elimination of spinlocks, thereby enhancing parallelism / performance. The embodiments described herein enable faster overall access to shared resources (i.e., dynamic memory, peripheral buffer pools, etc.) by providing lock-free access to resources shared across cores / threads. The embodiments described herein can perform operations such as allocation, deallocation, and resource pool rebalancing in a lock-free manner to maximize parallelism.

[0137] The embodiments described herein can be used in low-latency and high-bandwidth systems. The embodiments described herein enable faster operation of real-time multi-core applications. The embodiments described herein manage shared resources (such as optimized smaller memory) with optimal sizes. The embodiments described herein avoid locking spinlocks by having dedicated resource pools and metadata per core / per thread. The embodiments described herein utilize a release queue management system with exclusive subqueue sets. The embodiments described herein support cross-core deallocation of resources. The embodiments described herein monitor the occupancy level of each memory pool and dynamically adjust the allocation of each pool in a lock-free manner. The embodiments described herein dynamically determine when to reallocate dedicated memory per core / per thread.

[0138] The embodiments disclosed herein can be implemented by at least one software program that runs on at least one hardware device and performs network management functions to control the elements. Figure 4 The element shown can be at least one of a hardware device or a combination of a hardware device and a software module.

[0139] The foregoing description of the specific embodiments so fully reveals the general nature of the embodiments herein that others can readily modify and / or adapt them to various applications of such specific embodiments by applying present knowledge without departing from the overall conception, and therefore, such adaptations and modifications should and are intended to be included within the meaning and scope of equivalents of the disclosed embodiments. It will be understood that the wording or terminology used herein is for descriptive purposes and not for limitation. Therefore, although embodiments herein have been described with reference to examples, those skilled in the art will recognize that the embodiments herein can be practiced with modifications within the spirit and scope of the embodiments as described herein.< / variable>

Claims

1. A method for managing shared resources in a multi-core processor (102), comprising: Access shared resources associated with the source processing core (102a), wherein the source processing core (102a) and at least one target processing core (102b) reside in the multi-core processor (102); Based on the accessed shareable resources, multiple release sub-queues are generated in the release queue of the source processing core (102a) corresponding to each target processing core in at least one target processing core (102b); Based on the analysis of first information related to the shareable resource, at least one accessed shareable resource is released to multiple release sub-queues generated in the release queue of the source processing core (102a), wherein the first information related to the shareable resource is stored in a metadata file corresponding to the source processing core (102a); and Based on the identification of the release of shareable resources in the release queue, the second information in the metadata file is updated. The first piece of information related to the shareable resources includes the pool ID, the assigned shareable resource ID, the resource block ID, and the assigned core ID.

2. The method as described in claim 1, wherein, The method further includes: Based on the determined type of task to be run by the multi-core processor (102), at least one shareable resource stored in memory (104) is assigned to the at least one target processing core (102b). First information relating to the at least one assigned shareable resource is stored in a metadata file corresponding to the source processing core (102a); Based on information stored in the metadata file, the at least one target processing core (102b) is provided with access to the at least one assigned shareable resource; and Whether the at least one shared resource accessed corresponds to a source processing core (102a) is determined based on the stored metadata file, wherein the at least one shared resource accessed is determined by the at least one target processing core (102b) based on the access to the at least one shared resource.

3. The method as described in claim 1, wherein, The method further includes: Determine the available space for each release subqueue in the release queue; Determine whether the available space for each released subqueue is higher or lower than a predefined threshold; Update the information corresponding to the free list and busy list of available space for each release subqueue in the metadata file corresponding to the source processing core (102a) and the at least one target processing core (102b); If the available space of each release subqueue is determined to be below the predefined threshold, then based on the updated metadata file, a deficiency flag corresponding to the source processing core (102a) and the at least one target processing core (102b) is set; and If the available space in the release subqueue is determined to be below the predefined threshold, the shareable resources of the source processing core (102a) are pushed to the release subqueue marked in the free list by dynamically adjusting the pool size of the release queue.

4. The method of claim 1, wherein, The method further includes: If the release queue corresponding to the source processing core (102a) has available space, the release of the shared resource is triggered during the assignment of the shared resource; and If the release queue corresponding to the source processing core (102a) has available space, the release of the shared resource is prompted during the release of the shared resource to the release queue.

5. The method of claim 1, wherein, The method further includes: Parse the metadata file to determine at least one of the following: pool ID, free list of pool IDs, busy list of pool IDs, and assigned shareable resource ID.

6. The method of claim 1, wherein, The shareable resources include at least one of the following: memory (104) resources, common peripheral resources, serial port resources, parallel port resources, display resources, audio resources, multi-core processor (102) resources, central processing unit resources, logic processor resources, input / output resources, channel resources, coprocessor resources, and network adapter resources; and wherein the source processing core (102a) and the at least one target processing core (102b) of the multi-core processor (102) include at least one of core 0, core 1, core 2, and core 3.

7. The method of claim 2, wherein, The step of assigning the at least one shareable resource includes: allocating a memory block in memory (104) to each of the source processing core (102a) and the at least one target processing core (102b) to access the shareable resource in the memory block.

8. The method of claim 1, wherein, Metadata files are generated for each of the source processing core (102a) and the at least one target processing core (102b), and are stored sequentially according to the order of each processing core; and The release queue corresponding to the source processing core (102a) includes at least one entry queue corresponding to the at least one target processing core (102b).

9. The method of claim 8, wherein, The step of releasing the at least one shareable resource includes updating the at least one entry queue corresponding to the at least one target processing core (102b).

10. The method of claim 1, wherein, Shared resources are assigned by the source processing core (102a) and released by the at least one target processing core (102b).

11. A method for managing shared resources in a multi-core processor (102), comprising: Shared resources from memory (104) are allocated to at least one target processing core (102b), wherein the source processing core (102a) and the target processing core (102b) reside in the multi-core processor (102); Update the information related to the shareable resources in the metadata file corresponding to the source processing core (102a); Access the allocated shared resources from memory (104); Releasing the allocated shareable resources, wherein the step of releasing the allocated shareable resources includes: releasing the shareable resources to a plurality of release subqueues corresponding to each of the at least one target processing core (102b) in a release queue corresponding to the source processing core (102a); Based on checking the release queue corresponding to the source processing core (102a), the release of shareable resources by the target processing core (102b) is identified; and The source processing core (102a) updates the metadata file corresponding to the source processing core (102a). The information related to the shareable resources includes the pool ID, the assigned shareable resource ID, the resource block ID, and the assigned core ID.

12. The method of claim 11, wherein, The release queue corresponding to the source processing core (102a) includes at least one entry queue corresponding to the at least one target processing core (102b).

13. The method of claim 11, wherein, The step of releasing the shareable resources to the plurality of release subqueues includes: updating at least one entry queue corresponding to the at least one target processing core (102b).

14. A device (100) for managing shared resources in a multi-core processor (102), wherein, The device (100) includes at least one processor configured to perform the method as described in any one of claims 1-13.

Images