CC-NUMA server, lock request processing method and related device

Abstract

The present application discloses a CC-NUMA server, a method for processing lock requests, and related devices, and belongs to the field of computers. The CC-NUMA server includes multiple processors and a shared device, the multiple processors are connected to each other via a CC-NUMA bus, and the multiple processors are also respectively connected to the shared device via a CC-NUMA bus; each processor has a cache and a memory, and the shared device has a shared memory, and the shared memory is used to store the locks corresponding to the shared resources of the multiple processors. In the present application, the multiple processors can determine whether the locks corresponding to the shared resources are occupied by accessing the shared memory, without having to determine whether the locks corresponding to the shared resources are occupied by accessing the memory of a certain processor, thereby avoiding the migration of the locks corresponding to the shared resources between the caches or memories of different processors, and also avoiding the problem of a large number of synchronization messages caused by maintaining cache consistency, thereby improving application performance.

Description

[0001] This application is a divisional application. The application number of the original application is 202310433205.8, and the original application date is April 17, 2023. The entire content of the original application is incorporated into this application by reference. Technical Field

[0002] The present application relates to the field of computers, and in particular to a cache coherent non-uniform memory access (CC-NUMA) server, a lock request processing method, and related devices. Background Art

[0003] A CC-NUMA server typically includes multiple processors interconnected by a low-latency bus. Each processor has cache and memory. Each processor can access not only its local memory but also the memory of other processors (i.e., remote memory) via the low-latency bus. These processors also maintain cache coherence across processors using a cache coherence protocol.

[0004] The multiple processors have a large number of shared resources. When a thread needs to access a shared resource, it can apply to occupy the lock corresponding to the shared resource, thereby obtaining the right to access the shared resource. This process is also called locking. Other threads that fail to occupy the lock need to wait until the lock's occupation status is released before they can apply to occupy the lock. Usually, after completing the task of accessing the shared resource, the thread occupying the lock will actively release the occupation of the lock. This process is also called unlocking. However, with the continuous development of chip technology, the processor includes more and more cores, and the performance of the locks corresponding to the shared resources of the multiple processors is becoming more and more important. Therefore, how to process the lock request has become a problem that needs to be solved urgently. Summary of the Invention

[0005] This application provides a CC-NUMA server, a lock request processing method, and related devices that can prevent locks corresponding to shared resources from migrating between caches or memories of different processors, and can also avoid the problem of a large number of synchronization messages caused by maintaining cache consistency, thereby improving application performance. The technical solution is as follows:

[0006] In a first aspect, a CC-NUMA server is provided, comprising a plurality of processors and a shared device, wherein the plurality of processors are connected to each other via a CC-NUMA bus, and the plurality of processors are also respectively connected to the shared device via the CC-NUMA bus; each of the plurality of processors has a cache and a memory, the shared device has a shared memory, and the shared memory is used to store locks corresponding to shared resources of the plurality of processors.

[0007] This application uses shared memory to store the locks corresponding to the shared resources of the multiple processors, rather than using the processor's memory. In this way, the multiple processors can determine whether the lock corresponding to the shared resource is occupied by accessing the shared memory, without having to access the memory of a specific processor to determine whether the lock corresponding to the shared resource is occupied. This prevents the lock corresponding to the shared resource from migrating between the caches or memories of different processors, and also avoids the problem of a large number of synchronization messages caused by maintaining cache consistency, thereby improving application performance.

[0008] In addition, since the shared memory is the memory of a shared device outside the multiple processors and not the memory of a certain processor, the latency for each processor to access the shared memory is basically the same. Therefore, using the shared memory to store the locks corresponding to the shared resources can also avoid the problem of asymmetric memory access latency caused by the CC-NUMA architecture, thereby avoiding the problem of unfairness in the occupation of locks corresponding to shared resources by threads on different processors.

[0009] Optionally, the shared memory and the memories of the multiple processors are globally and uniformly addressed. That is, during the system startup phase, the CC-NUMA server can map the physical address space of the shared memory on the shared device to the address space addressable by the processor, thereby facilitating processor access to the shared memory.

[0010] Optionally, the shared memory includes a first memory area and a second memory area, wherein the first memory area is used to store a first type of lock, and the second memory area is used to store a second type of lock. The first type of lock cannot be cached by the multiple processors, while the second type of lock can be cached by the multiple processors. In other words, the shared memory can be divided into two memory areas to support different types of locks.

[0011] Since the lock corresponding to the shared resource may or may not need to maintain cache consistency, that is, when the type of lock corresponding to the shared resource is different, the characteristics of whether the lock needs to maintain cache consistency will also be different. Therefore, after dividing the shared memory into the first memory area and the second memory area, the cache properties of the first memory area and the second memory area can be set to support different types of locks.

[0012] Optionally, the first type of lock includes a mutual exclusion lock and a basic spin lock, and the second type of lock includes a high-performance spin lock. A basic spin lock may also be referred to as a simple spin lock or a first spin lock, such as a spin lock. A high-performance spin lock includes an MCS lock, which may also be referred to as a second spin lock. The performance of the second spin lock is higher than that of the first spin lock.

[0013] In the case where a loop array corresponding to the high-performance spin lock is stored in the second memory area, the loop array includes at least one array element, the at least one array element is located in a continuous physical address space, the at least one array element corresponds one-to-one to at least one thread applying to occupy the high-performance spin lock, the previous array element in the at least one array element points to the next array element, and the array element indicates whether the corresponding thread has occupied the high-performance spin lock.

[0014] Optionally, the size of each of the at least one array element is the same as the size of a cache line in the caches of the multiple processors. Therefore, the array element corresponding to each thread can not only be stored in the second memory area, but also cached in the local cache of the processor. This can avoid frequent access to shared memory and cache synchronization operations caused by different processors accessing the same array element.

[0015] Optionally, the CC-NUMA bus supports memory semantic access.

[0016] When a processor accesses its own local memory, it usually accesses it at the granularity of a cache line. In other words, the data size that the processor accesses the local memory is usually the same as the cache line size. This method of accessing memory at the granularity of a cache line in a synchronous manner can be called memory semantic access. However, for a shared device, when a processor accesses the memory of a shared device, it usually accesses it through asynchronous IO semantics, and does not support memory semantic access. In this application, the shared device supports memory semantic access, and the processor and the shared device are connected through a CC-NUMA bus, thereby supporting the processor to access the shared memory of the shared device in a memory semantic manner, thereby reducing the latency of the processor accessing the shared memory.

[0017] In a second aspect, a method for processing a lock request is provided, which is characterized in that it is applied to a CC-NUMA server, the CC-NUMA server includes multiple processors and a shared device, the shared device includes a shared memory, and the shared memory is used to store locks corresponding to shared resources of the multiple processors. The method includes: receiving a lock request sent by a target thread, the lock request is used to request to occupy a target lock, the target lock is a lock corresponding to a target resource, and the target resource is any resource shared by the multiple processors; determining the occupancy status of the target lock from the shared memory, the occupancy status indicates whether the target lock is currently occupied; and processing the lock request based on the occupancy status.

[0018] This application uses shared memory to store the locks corresponding to the shared resources of the multiple processors, rather than using the processor's memory. In this way, the multiple processors can determine whether the lock corresponding to the shared resource is occupied by accessing the shared memory, without having to access the memory of a specific processor to determine whether the lock corresponding to the shared resource is occupied. This prevents the lock corresponding to the shared resource from migrating between the caches or memories of different processors, and also avoids the problem of a large number of synchronization messages caused by maintaining cache consistency, thereby improving application performance.

[0019] In addition, since the shared memory is the memory of a shared device outside the multiple processors and not the memory of a certain processor, the latency for each processor to access the shared memory is basically the same. Therefore, using the shared memory to store the locks corresponding to the shared resources can also avoid the problem of asymmetric memory access latency caused by the CC-NUMA architecture, thereby avoiding the problem of unfairness in the occupation of locks corresponding to shared resources by threads on different processors.

[0020] The lock request is used to request the occupation of the target lock to obtain access rights to the target resource. In some implementations, the lock request carries the identifier of the target resource and the identifier of the target thread, requesting that access rights to the target resource be assigned to the target thread. The access rights include read and write permissions.

[0021] In some implementations, determining the occupancy of the target lock from the shared memory includes: obtaining a user-state virtual address of the target lock; determining the kernel-state virtual address of the target lock based on the user-state virtual address of the target lock through a mapping relationship between the user-state virtual address space and the kernel-state virtual address space of the shared memory; determining the physical address of the target lock in the shared memory based on the kernel-state virtual address of the target lock through a mapping relationship between the kernel-state virtual address space and the physical address space of the shared memory; and determining the occupancy of the target lock from the shared memory based on the physical address.

[0022] Based on the above description, the lock request carries the identifier of the target resource, so the user-mode virtual address of the target lock can be obtained based on the identifier of the target resource.

[0023] During initialization, the locks corresponding to the shared resources of the multiple processors can be stored in the shared memory, and the user-state virtual address of the lock corresponding to each shared resource can be determined from the user-state virtual address space of the shared memory. The identifier of each shared resource and the user-state virtual address of the lock corresponding to each shared resource can be stored in the corresponding relationship between resource identifiers and user-state virtual addresses. In this way, after receiving a lock request, the corresponding user-state virtual address can be obtained from the corresponding relationship between the stored resource identifiers and user-state virtual addresses based on the identifier of the target resource, and the obtained user-state virtual address can be determined as the user-state virtual address of the target lock.

[0024] Since the shared memory is located in the kernel space and the target thread is located in the user space, the user space application cannot directly access the kernel space. Therefore, before determining the occupancy of the target lock from the shared memory, the method further includes: determining the size of the shared memory from the configuration space corresponding to the shared device; allocating a kernel virtual address space to the shared memory based on the size of the shared memory, and establishing a mapping relationship between the physical address space of the shared memory and the kernel virtual address space; determining the user virtual address space of the shared memory based on the kernel virtual address space, and establishing a mapping relationship between the kernel virtual address space and the user virtual address space. In this way, after determining the user virtual address of the target lock, the physical address of the target lock in the shared memory can be determined through the mapping relationship between the user virtual address space, kernel virtual address space, and physical address space of the shared memory, and then determining the occupancy of the target lock from the shared memory based on the physical address of the target lock in the shared memory.

[0025] Optionally, the shared memory includes a first memory area and a second memory area, wherein the first memory area is used to store a first type of lock, and the second memory area is used to store a second type of lock, wherein the first type of lock is not allowed to be cached by the multiple processors, and the second type of lock is allowed to be cached by the multiple processors. In this case, determining the occupancy of the target lock from the shared memory includes: if the target lock belongs to the first type of lock, determining the occupancy of the target lock from the first memory area; if the target lock belongs to the second type of lock and the target lock does not exist in the cache of the processor corresponding to the target thread, determining the occupancy of the target lock from the second memory area.

[0026] Since the first type of lock does not allow the multiple processors to cache it, while the second type of lock allows it to be cached by the multiple processors, the first type of lock can only be stored in the first memory area, while the second type of lock is not only stored in the second memory area, but may also be stored in the processor's cache. In this case, it is necessary to determine whether the target lock belongs to the first type of lock or the second type of lock. If the target lock belongs to the first type of lock, the occupancy of the target lock can be determined directly from the first memory area. If the target lock belongs to the second type of lock, it is necessary to determine whether the target lock exists in the cache of the processor corresponding to the target thread. If the target lock exists in the cache of the processor, the occupancy of the target lock can be determined directly from the cache of the processor. If the target lock does not exist in the cache of the processor, the occupancy of the target lock is determined from the second memory area.

[0027] Optionally, before determining the occupancy status of the target lock from the shared memory, the method further includes: obtaining configuration information of the shared memory from the configuration space corresponding to the shared device, the configuration information including the size of the first memory area and the size of the second memory area; dividing the shared memory into a first memory area and a second memory area based on the configuration information of the shared memory; setting a cache attribute of the first memory area and a cache attribute of the second memory area, the cache attribute indicating whether the lock stored in the corresponding memory area is allowed to be cached by the multiple processors.

[0028] If the target lock is currently occupied, it is determined that other threads currently have access rights to the target resource, and in this case, the access rights to the target resource are not assigned to the target thread. If the target lock is currently unoccupied, it is determined that no thread currently has access rights to the target resource, and in this case, the access rights to the target resource are assigned to the target thread.

[0029] The target lock is a mutex lock or a basic spin lock, and both the mutex lock and the basic spin lock are stored in the first memory area. For a mutex lock, the processor can determine the occupancy of the mutex lock from the first memory area. If the mutex lock is not currently occupied, it is determined that the target thread occupies the mutex lock, and the access rights of the target resource are allocated to the target thread. If the mutex lock is currently occupied, the target thread is blocked, thereby entering a sleep state, until the mutex lock is released, and the target thread is awakened from the sleep state to resume execution. For a basic spin lock, the processor can determine the occupancy of the basic spin lock from the first memory area. If the basic spin lock is not currently occupied, it is determined that the target thread occupies the basic spin lock, and the access rights of the target resource are allocated to the target thread. If the basic spin lock is currently occupied, the basic spin lock is read cyclically until the basic spin lock is released and then occupied.

[0030] In some implementations, to prevent the base spin lock from being frequently read, when the processor determines that the base spin lock is currently occupied, a low-power instruction may be executed to instruct the core or processor where the target thread is located to sleep for a period of time or enter a low-power state to wait for awakening. For example, the low-power instruction may be a Pause instruction or a Wait for Event (WFE) instruction.

[0031] The target lock is a high-performance spin lock stored in a second memory area. The second memory area stores a loop array corresponding to the high-performance spin lock. The loop array includes at least one array element located in a continuous physical address space. The at least one array element corresponds one-to-one with at least one thread applying to occupy the high-performance spin lock. The previous array element in the at least one array element points to the next array element, which indicates whether the corresponding thread has occupied the high-performance spin lock.

[0032] In some implementations, each array element includes a first variable and a second variable, where the first variable indicates whether the corresponding thread has occupied the high-performance spin lock, and the second variable indicates the physical address where the next array element is stored. For example, if the thread has occupied the high-performance spin lock, the value of the first variable is 1, and if the thread has not occupied the high-performance spin lock, the value of the first variable is 0. That is, the value of the first variable in at most one of the at least one array element is 1, and the value of the first variable in the other numerical elements is 0.

[0033] Since the at least one array element is located in a continuous physical address space, and a continuous physical address space is usually located in the same page table, when the value of the first variable in the previous array element is updated based on the physical address indicated by the second variable in the previous array element, an address conversion can be performed through the mapping relationship between the virtual address and the physical address of this page table. In this way, there is no need to perform address conversion again for subsequent array elements.

[0034] In some implementations, the size of each of the at least one array element is the same as the cache line size. Therefore, the array element corresponding to each thread can not only be stored in the second memory area, but also cached in the local cache of the processor. This can avoid frequent access to shared memory and cache synchronization operations caused by different processors accessing the same array element.

[0035] When the second type of lock includes a high-performance spin lock, the high-performance spin lock is not only stored in the second memory area, but may also be stored in the processor's cache. When the high-performance spin lock is stored in the processor's cache, the high-performance spin lock cached by each processor can be called a private lock. That is, each processor cache has its own corresponding array element, and each corresponding array element indicates the occupancy status of its own private lock. Each processor determines whether the high-performance spin lock is currently occupied by accessing its own private lock, without having to access the second memory area to determine whether the high-performance spin lock is currently occupied, thereby avoiding frequent access to shared memory.

[0036] In a third aspect, a lock request processing device is provided, wherein the device has the function of implementing the lock request processing method described in the second aspect. The device includes at least one module configured to implement the method described in the second aspect.

[0037] In a fourth aspect, a CC-NUMA server is provided, comprising a processor and a memory, wherein the memory is configured to store a computer program for executing the method provided in the second aspect. The processor is configured to execute the computer program stored in the memory to implement the method provided in the second aspect.

[0038] Optionally, the CC-NUMA server may further include a communication bus, where the communication bus is used to establish a connection between the processor and the memory.

[0039] In a fifth aspect, a computer-readable storage medium is provided, wherein the storage medium stores instructions. When the instructions are executed on a computer, the computer executes the steps of the method described in the second aspect.

[0040] In a sixth aspect, a computer program product comprising instructions is provided, which, when executed on a computer, causes the computer to perform the steps of the method described in the second aspect. Alternatively, a computer program is provided, which, when executed on a computer, causes the computer to perform the steps of the method described in the second aspect.

[0041] The technical effects obtained in the above-mentioned third to sixth aspects are similar to the technical effects obtained by the corresponding technical means in the first or second aspect, and will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0042] Figure 1 This is a structural diagram of a CC-NUMA server provided in an embodiment of the present application;

[0043] Figure 2This is a schematic diagram of allocating kernel-mode virtual address space and user-mode virtual address space to shared memory, provided by an embodiment of the present application;

[0044] Figure 3 This is a flowchart of a method for processing a lock request provided by an embodiment of the present application;

[0045] Figure 4 Schematic diagram of a method for processing a lock request for a mutex lock or a basic spin lock provided in an embodiment of the present application;

[0046] Figure 5 Schematic diagram of a high-performance spin lock lock request processing method provided in an embodiment of the present application;

[0047] Figure 6 It is a structural diagram of a lock request processing device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0048] In order to make the objectives, technical solutions and advantages of the embodiments of the present application clearer, the implementation methods of the present application will be further described in detail below with reference to the accompanying drawings.

[0049] Before explaining in detail the CC-NUMA server and the lock request processing method provided in the embodiments of the present application, the terminology and implementation environment involved in the embodiments of the present application are first introduced.

[0050] First, the terms involved in the embodiments of the present application are introduced.

[0051] 1. Non-uniform memory access (NUMA)

[0052] In a multi-processor system based on the NUMA architecture, each processor has its own memory. Each processor can access not only its own memory but also the memory of other processors. For any one of these processors, its own memory is relatively close, and its own memory is often called local memory. The memory of other processors is relatively far away, and the memory of other processors is often called remote memory or non-local memory.

[0053] NUMA technology is a memory access architecture designed for multiprocessors. In a NUMA-based multiprocessor system, memory access time depends on the relative location of the processor and the memory. That is, a processor accesses local memory faster than non-local memory.

[0054] 2. CC-NUMA

[0055] CC-NUMA can also be called cache-consistent NUMA architecture. This architecture mainly ensures cache consistency between multiple processors on the NUMA architecture, reducing the difficulty of writing system programs.

[0056] 3. Cache line

[0057] A cache is hardware that caches data in memory. A cache line is the basic unit of cache memory. The cache line size refers to the size of the data in a cache line. When the processor accesses memory, it copies data from memory into the cache in units of the cache line size. For example, if the cache line size is N bytes, the processor will copy at least N bytes of data from memory to the cache at a time when accessing memory. For example, the cache line size is typically 64 bytes.

[0058] 4. Critical Section

[0059] When two threads compete for the same resource, and the order in which they access the resource is sensitive, a race condition exists. The code section that causes the race condition is called a critical section. In other words, the code section where two threads compete for the same resource is called a critical section.

[0060] 5. Semaphore

[0061] Semaphores, sometimes called semaphores, are a mechanism used in multithreaded environments to ensure that two or more threads cannot access the same shared resource simultaneously. Before accessing a shared resource, a thread must acquire a semaphore. Once access is complete, the thread must release the semaphore. Other threads wishing to access the resource must wait until the previous thread releases the semaphore. In other words, semaphores coordinate threads to ensure they use shared resources correctly and appropriately.

[0062] In abstract terms, a semaphore controls access to shared resources through a counter. The value of the semaphore is a non-negative integer. All threads that pass through it will decrement the integer by one. When the integer value is zero, all threads attempting to pass through it will be in a waiting state. In other words, the result of the counter calculation is a pass that allows access to shared resources. In order to access shared resources, a thread must obtain a pass from the semaphore. If the semaphore count is greater than 0, the thread obtains a pass, which will cause the semaphore count to decrement. Otherwise, the thread will block until it obtains a pass. When the thread no longer needs to access the shared resource, it releases the pass, which causes the semaphore count to increment. If another thread is waiting for a pass, the thread will obtain the pass.

[0063] 6. Mutex

[0064] A mutex lock allows only one user to access a resource at a time, which is unique and exclusive. However, a mutex lock cannot restrict the order in which users access the resource, meaning access is unordered.

[0065] Before a thread accesses a shared resource, it can apply for a mutex lock. If the mutex lock is already held by another thread, the thread will enter a blocked state, or sleep state. The thread will only wake up from the blocked state after the mutex lock is released.

[0066] 7. Spinlock

[0067] Spinlocks and mutexes are similar in that they both guarantee mutually exclusive access to a resource. Both a mutex and a spinlock can have at most one holder at any given time, meaning that at most one thread can acquire the lock. However, their scheduling mechanisms differ slightly. For a mutex, if the mutex is already held, the thread must enter a sleep state. However, a spinlock does not cause a thread to sleep. If the spinlock is already held by another thread, the thread will remain in loop until the other thread releases the spinlock.

[0068] Next, the implementation environment involved in the embodiments of this application is introduced.

[0069] A CC-NUMA server typically includes multiple processors interconnected by a low-latency bus. Each processor has cache and memory. Each processor can access not only its local memory but also the memory of other processors (i.e., remote memory) via the low-latency bus. These processors also maintain cache coherence across processors using a cache coherence protocol.

[0070] The multiple processors have a large number of shared resources, such as last level cache (LLC), memory, and input / output (IO) devices. However, multi-core multi-threaded applications must control access to these shared resources to ensure that they can only be used by a single thread at any time. When a thread enters a critical section, multiple threads must access the shared resources in a mutually exclusive manner. To ensure that shared resources accessed in the critical section code are mutually exclusive and prevent different threads from accessing the same resource simultaneously, it is necessary to introduce "lock" mechanisms such as semaphores, mutexes, and spin locks. Atomic operations on lock variables are guaranteed through the memory of the multiple processors and the memory access atomic instructions provided by the processors.

[0071] Among them, when a thread is waiting for the thread holding the semaphore and mutex to release the lock, it will enter a sleep state, while the spin lock is a thread idling while waiting for the lock to be released. Therefore, it is more efficient for scenarios where the lock can be acquired quickly, but if the thread waits for the spin lock to be released for a long time, it is extremely wasteful of processor resources.

[0072] With the continuous development of chip technology, the number of cores integrated into processors has increased. Lock performance, especially the performance of multi-processor global shared locks, has become increasingly important. However, due to the asymmetric memory access latency brought by the CC-NUMA architecture, the optimization of multi-processor shared locks has become one of the key factors affecting the effective computing power of applications. To this end, embodiments of the present application provide a CC-NUMA server and a lock request processing method that can improve the performance of accessing shared resources.

[0073] Please refer to Figure 1 , Figure 1 1 is a schematic diagram of the structure of a CC-NUMA server provided in an embodiment of the present application. The CC-NUMA server includes multiple processors 101 ( Figure 1 The multiple processors 101 are connected via a CC-NUMA bus ( Figure 1 The processors 101 are connected to the shared device 102 via a CC-NUMA bus. Each processor 101 has a cache and memory. The shared device 102 includes a shared memory for storing locks corresponding to the shared resources of the processors 101.

[0074] In the embodiment of the present application, the locks corresponding to the shared resources of the multiple processors are stored in shared memory, rather than in the memory of the processors. Thus, the multiple processors can determine whether the locks corresponding to the shared resources are occupied by accessing the shared memory, without having to access the memory of a particular processor. This prevents the locks corresponding to the shared resources from migrating between the caches or memories of different processors, and also avoids the problem of a large number of synchronization messages caused by maintaining cache coherence, thereby improving application performance.

[0075] In addition, since the shared memory is the memory of a shared device outside the multiple processors and not the memory of a certain processor, the latency for each processor to access the shared memory is basically the same. Therefore, using the shared memory to store the locks corresponding to the shared resources can also avoid the problem of asymmetric memory access latency caused by the CC-NUMA architecture, thereby avoiding the problem of unfairness in the occupation of locks corresponding to shared resources by threads on different processors.

[0076] The processor 101 may be a general-purpose central processing unit (CPU), a network processor (NP), a microprocessor, or one or more integrated circuits for implementing the solution of the present application, such as an application-specific integrated circuit (ASIC), a programmable logic device (PLD), or a combination thereof. The PLD may be a complex programmable logic device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL), or any combination thereof. The processor 101 may be a single-core processor or a multi-core processor.

[0077] Shared device 102 can be a CPU, a data processing unit (DPU), or any other device with processing capabilities. In some embodiments, shared device 102 can be referred to as an xPU. Shared memory can be a portion of the shared device 102's internal memory, which can be set to be invisible to the software running on shared device 102. That is, when shared device 102 starts up, the shared memory is not disclosed to the shared device's software system.

[0078] The CC-NUMA bus supports cache consistency and memory semantic access. When the multiple processors 101 are connected via the CC-NUMA bus, the caches between the multiple processors 101 can achieve cache consistency, and each processor 101 can access the local memory or remote memory in a memory semantic manner. Similarly, the shared device 102 supports memory semantic access. When the multiple processors 101 are respectively connected to the shared device 102 via the CC-NUMA bus, the multiple processors 101 can also access the shared memory of the shared device 102 in a memory semantic manner.

[0079] When the processor 101 accesses its own local memory, it usually accesses it at the granularity of the cache line. That is to say, the data size of the local memory accessed by the processor 101 is usually the same as the cache line size. This method of accessing the memory at the granularity of the cache line in a synchronous manner can be called memory semantic access. However, for the shared device 102, when the processor 101 accesses the memory of the shared device 102, it is usually accessed through asynchronous IO semantics, and memory semantic access is not supported. In the embodiment of the present application, the shared device 102 supports memory semantic access, and the processor 101 and the shared device 102 are connected through the CC-NUMA bus, thereby supporting the processor 101 to access the shared memory of the shared device 102 in a memory semantic manner, thereby reducing the latency of the processor 101 accessing the shared memory.

[0080] Based on the above description, the shared memory is invisible to the software system of the shared device 102 . Therefore, when the processor 101 accesses the shared memory, it is not necessary to maintain the cache consistency of the shared device 102 .

[0081] The cache of the processor 101 may include LLC, and the memory of the processor 101 may be double data rate synchronous dynamic random access memory (DDR SDRAM). Of course, the cache of the processor 101 also includes other forms of cache, and the memory of the processor 101 may also include other types of memory, which are not limited in the embodiments of the present application.

[0082] The memory of the processor 101 may be independent and connected to the processor 101 via a bus. Of course, the memory of the processor 101 may also be integrated with the processor 101.

[0083] In some embodiments, the shared memory and the memories of the multiple processors 101 can be globally and uniformly addressed. That is, during the system startup phase, the CC-NUMA server can map the physical address space of the shared memory on the shared device 102 to the address space addressable by the processor 101, thereby facilitating the processor 101 to access the shared memory.

[0084] The implementation process of the CC-NUMA server mapping the physical address space of the shared memory to the address space addressable by the processor 101 includes: determining the size of the shared memory from the configuration space corresponding to the shared device 102, allocating kernel-mode virtual address space to the shared memory based on the size of the shared memory, and establishing a mapping relationship between the physical address space of the shared memory and the kernel-mode virtual address space; then, based on the kernel-mode virtual address space of the shared memory, determining the user-mode virtual address space of the shared memory, and establishing a mapping relationship between the kernel-mode virtual address space of the shared memory and the user-mode virtual address space.

[0085] For example, please refer to Figure 2 The CC-NUMA server's operating system kernel has a kernel driver for shared devices installed. This kernel driver allocates kernel-mode virtual address space for shared memory and establishes a mapping between the shared memory's physical address space and the kernel-mode virtual address space. Furthermore, this kernel driver generates an IOCTL user-mode interface for the shared device. User-mode applications can use this IOCTL user-mode interface to allocate user-mode virtual address space for shared memory and establish a mapping between the shared memory's kernel-mode virtual address space and the user-mode virtual address space.

[0086] In some embodiments, the application may open the shared device through the fopen() system call and allocate user-mode virtual address space for the shared memory by calling a kernel application programming interface (API), such as remap_pfn_range().

[0087] The configuration space of the sharing device 102 stores the size of the shared memory, so the processor 101 can directly obtain the size of the shared memory from the configuration space of the sharing device 102. Furthermore, the shared memory is typically located in kernel space, and user-space applications cannot directly access kernel-space memory. Therefore, after obtaining the size of the shared memory, a kernel-mode virtual address space can be allocated for the shared memory based on the size of the shared memory, and a mapping relationship between the physical address space of the shared memory and the kernel-mode virtual address space can be established. Furthermore, the user-mode virtual address space corresponding to the kernel-mode virtual address space of the shared memory can be determined, and a mapping relationship between the kernel-mode virtual address space of the shared memory and the user-mode virtual address space can be established. In this way, user-space applications can access the shared memory through the mapping relationship between the user-mode virtual address space, the kernel-mode virtual address space, and the physical address space.

[0088] During system startup, the CC-NUMA server can poll the configuration space of each peripheral component interconnect express (PCIe) device to allocate address space to each PCIe device in the addressing space. Therefore, in the embodiment of the present application, the CC-NUMA server can identify the shared device and treat the shared device as a standard peripheral component interconnect express (PCIe) device, and then allocate address space to the shared memory by polling the configuration space of the shared device.

[0089] After globally addressing shared memory and processor memory, we estimated the latency of processors accessing shared memory using memory semantics and found that the latency is roughly equivalent to the latency of processors accessing their own LLCs. For example, assuming the shared memory is static random access memory (SRAM), we estimated that the latency of processors accessing SRAM is approximately 15ns, and the latency of processors accessing their own LLCs is also roughly 15ns. Since the latency of processors accessing shared memory is comparable to the latency of accessing the LLC, storing the locks corresponding to shared resources in shared memory has little impact on application performance.

[0090] In some embodiments, please refer to Figure 1 The shared memory includes a first memory area and a second memory area. The first memory area is used to store first-type locks, and the second memory area is used to store second-type locks. The first-type locks are not allowed to be cached by the multiple processors 101, while the second-type locks are allowed to be cached by the multiple processors 101. In other words, the shared memory can be divided into two memory areas to support different types of locks.

[0091] For example, shared memory configuration information is obtained from a configuration space of a shared device. Based on the shared memory configuration information, the shared memory is divided into a first memory region and a second memory region. The shared memory configuration information includes the size of the first memory region and the size of the second memory region. Then, a cache attribute of the first memory region and the second memory region is set. The cache attribute indicates whether locks stored in the corresponding memory region are allowed to be cached by the multiple processors.

[0092] After allocating kernel-mode virtual address space and user-mode virtual address space to the shared memory, the shared memory is divided into a first memory area and a second memory area, which is equivalent to dividing the kernel-mode virtual address space and user-mode virtual address space of the shared memory into two parts, respectively, thereby obtaining the kernel-mode virtual address space and user-mode virtual address space corresponding to the first memory area, and the kernel-mode virtual address space and user-mode virtual address space corresponding to the second memory area.

[0093] Since the lock corresponding to the shared resource may or may not need to maintain cache consistency, that is, when the type of lock corresponding to the shared resource is different, the characteristics of whether the lock needs to maintain cache consistency will also be different. Therefore, after dividing the shared memory into the first memory area and the second memory area, the cache properties of the first memory area and the second memory area can be set to support different types of locks.

[0094] In some embodiments, the first type of lock includes mutual exclusion locks and basic spin locks, and the second type of lock includes high-performance spin locks. Basic spin locks can also be called simple spin locks, such as the aforementioned spin lock. High-performance spin locks include MCS locks. The MCS in MCS locks refers to Mellor Crummey Scott, the names of the three inventors.

[0095] In the case where the second type of lock includes a high-performance spin lock, the second memory area stores a loop array corresponding to the high-performance spin lock, the loop array includes at least one array element, the at least one array element is located in a continuous physical address space, the at least one array element corresponds one-to-one to at least one thread applying to occupy the high-performance spin lock, the previous array element in the at least one array element points to the next array element, and the array element indicates whether the corresponding thread has occupied the high-performance spin lock.

[0096] In some embodiments, the size of each of the at least one array element is the same as the size of a cache line in the caches of the multiple processors. Therefore, the array element corresponding to each thread can not only be stored in the second memory area, but also cached in the local cache of the processor. This can avoid frequent access to shared memory and cache synchronization operations caused by different processors accessing the same array element.

[0097] In some embodiments, the CC-NUMA server further includes a communication interface, which uses any transceiver-like device for communicating with other devices or communication networks. The communication interface includes a wired communication interface and may also include a wireless communication interface. The wired communication interface may be, for example, an Ethernet interface. The Ethernet interface may be an optical interface, an electrical interface, or a combination thereof. The wireless communication interface may be a wireless local area network (WLAN) interface, a cellular network communication interface, or a combination thereof.

[0098] In some embodiments, the CC-NUMA server further includes an output device and an input device. The output device communicates with the processor 101 and can display information in various ways. For example, the output device can be a liquid crystal display (LCD), a light emitting diode (LED) display device, a cathode ray tube (CRT) display device, or a projector. The input device communicates with the processor 101 and can receive user input in various ways. For example, the input device can be a mouse, keyboard, touch screen device, or sensor device.

[0099] Figure 3 This is a flowchart of a method for processing a lock request provided by an embodiment of the present application. The method is applied to a CC-NUMA server, which includes multiple processors and a shared device, the shared device includes a shared memory, and the shared memory is used to store locks corresponding to the shared resources of the multiple processors. Please refer to Figure 3 , the method includes the following steps.

[0100] Step 301: The processor receives a lock request sent by a target thread, where the lock request is used to request to occupy a target lock, where the target lock is a lock corresponding to a target resource, and the target resource is any resource shared by the multiple processors.

[0101] The lock request is used to request the occupation of the target lock to obtain access rights to the target resource. In some embodiments, the lock request carries the identifier of the target resource and the identifier of the target thread to request that access rights to the target resource be assigned to the target thread. The access rights include read permission and write permission.

[0102] The target lock may be a semaphore, a mutex lock, a spin lock, an MCS lock, etc., which is not limited in the embodiment of the present application.

[0103] Step 302: The processor determines the occupancy status of the target lock from the shared memory, where the occupancy status indicates whether the target lock is currently occupied.

[0104] In some embodiments, a user-state virtual address of a target lock is obtained, and based on the user-state virtual address of the target lock, the kernel-state virtual address of the target lock is determined through a mapping relationship between the user-state virtual address space of the shared memory and the kernel-state virtual address space, and based on the kernel-state virtual address of the target lock, the physical address of the target lock in the shared memory is determined through a mapping relationship between the kernel-state virtual address space of the shared memory and the physical address space, and based on the physical address of the target lock in the shared memory, the occupancy of the target lock is determined from the shared memory.

[0105] Based on the above description, the lock request carries the identifier of the target resource, so the user-mode virtual address of the target lock can be obtained based on the identifier of the target resource.

[0106] In some embodiments, during initialization, the locks corresponding to the shared resources of the multiple processors can be stored in a shared memory, and the user-state virtual address of the lock corresponding to each shared resource can be determined from the user-state virtual address space of the shared memory. The identifier of each shared resource and the user-state virtual address of the lock corresponding to each shared resource can be stored in the corresponding relationship between resource identifiers and user-state virtual addresses. In this way, after receiving a lock request, based on the identifier of the target resource, the corresponding user-state virtual address can be obtained from the corresponding relationship between the stored resource identifiers and user-state virtual addresses, and the obtained user-state virtual address can be determined as the user-state virtual address of the target lock.

[0107] Since the shared memory is located in kernel space and the target thread is located in user space, applications in user space cannot directly access kernel space. Therefore, before determining the occupancy of the target lock from the shared memory, the method further includes: determining the size of the shared memory from the configuration space corresponding to the shared device; allocating kernel-mode virtual address space to the shared memory based on the size of the shared memory; and establishing a mapping relationship between the physical address space of the shared memory and the kernel-mode virtual address space; determining the user-mode virtual address space of the shared memory based on the kernel-mode virtual address space of the shared memory; and establishing a mapping relationship between the kernel-mode virtual address space of the shared memory and the user-mode virtual address space. In this way, after determining the user-mode virtual address of the target lock, the physical address of the target lock in the shared memory can be determined based on the mapping relationship between the user-mode virtual address space, kernel-mode virtual address space, and physical address space of the shared memory. Furthermore, based on the physical address of the target lock in the shared memory, the occupancy of the target lock can be determined from the shared memory.

[0108] In some embodiments, the shared memory includes a first memory area and a second memory area, the first memory area being used to store a first type of lock, and the second memory area being used to store a second type of lock. The first type of lock is not permitted to be cached by the multiple processors, while the second type of lock is permitted to be cached by the multiple processors. In this case, the process of determining the occupancy of the target lock from the shared memory includes: if the target lock belongs to the first type of lock, determining the occupancy of the target lock from the first memory area; if the target lock belongs to the second type of lock and the target lock does not exist in the cache of the processor corresponding to the target thread, determining the occupancy of the target lock from the second memory area.

[0109] Since the first type of lock does not allow the multiple processors to cache it, while the second type of lock allows it to be cached by the multiple processors, the first type of lock can only be stored in the first memory area, while the second type of lock is not only stored in the second memory area, but may also be stored in the processor's cache. In this case, it is necessary to determine whether the target lock belongs to the first type of lock or the second type of lock. If the target lock belongs to the first type of lock, the occupancy of the target lock can be determined directly from the first memory area. If the target lock belongs to the second type of lock, it is necessary to determine whether the target lock exists in the cache of the processor corresponding to the target thread. If the target lock exists in the cache of the processor, the occupancy of the target lock can be determined directly from the cache of the processor. If the target lock does not exist in the cache of the processor, the occupancy of the target lock is determined from the second memory area.

[0110] Based on the description above, the latency for a processor to access shared memory is roughly the same as the latency for accessing its own LLC. However, the latency for a processor to access its own LLC is typically lower than the latency for accessing its own memory. Therefore, storing locks corresponding to shared resources in shared memory can improve lock request processing efficiency compared to storing locks in the processor's own memory. For example, the latency for a processor to access its own memory is 80ns.

[0111] In some embodiments, the first type of lock includes a mutual exclusion lock and a basic spin lock, and the second type of lock includes a high-performance spin lock. Of course, in actual applications, the first type of lock and the second type of lock may also include other types of locks. For example, the first type of lock may include a semaphore, which is not limited in this embodiment of the present application.

[0112] In some embodiments, before determining the occupancy status of the target lock from the shared memory, it also includes: obtaining configuration information of the shared memory from the configuration space corresponding to the shared device, the configuration information including the size of the first memory area and the size of the second memory area, based on the configuration information of the shared memory, dividing the shared memory into the first memory area and the second memory area, setting the cache attribute of the first memory area and the cache attribute of the second memory area, the cache attribute indicating whether the lock stored in the corresponding memory area is allowed to be cached by the multiple processors.

[0113] After setting the cache attributes of the first memory area and the cache attributes of the second memory area, and storing the locks corresponding to the shared resources of the multiple processors in the first memory area or the second memory area, the processor can determine whether to store the locks in the first memory area in the processor's cache based on the cache attributes of the first memory area, and determine whether to store the locks in the second memory area in the processor's cache based on the cache attributes of the second memory area.

[0114] Step 303: The processor processes the lock request based on the occupancy of the target lock.

[0115] If the target lock is currently occupied, it is determined that other threads currently have access rights to the target resource, and in this case, the access rights to the target resource are not assigned to the target thread. If the target lock is currently unoccupied, it is determined that no thread currently has access rights to the target resource, and in this case, the access rights to the target resource are assigned to the target thread.

[0116] For example, Figure 4 As shown, the target lock is a mutex or a basic spin lock, and both the mutex and the basic spin lock are stored in the first memory area. For a mutex, the processor can determine the occupancy of the mutex from the first memory area. If the mutex is not currently occupied, it is determined that the target thread occupies the mutex, and the access rights of the target resource are assigned to the target thread. If the mutex is currently occupied, the target thread is blocked, thereby entering a sleep state, until the mutex is released, the target thread is awakened from the sleep state, thereby resuming execution. For a basic spin lock, the processor can determine the occupancy of the basic spin lock from the first memory area. If the basic spin lock is not currently occupied, it is determined that the target thread occupies the basic spin lock, and the access rights of the target resource are assigned to the target thread. If the basic spin lock is currently occupied, the basic spin lock is read cyclically until the basic spin lock is released and then occupied.

[0117] In some embodiments, to prevent the base spin lock from being frequently read, when the processor determines that the base spin lock is currently occupied, a low-power instruction may be executed to instruct the core or processor where the target thread is located to sleep for a period of time or enter a low-power state to wait for awakening. For example, the low-power instruction may be a Pause instruction or a Wait for Event (WFE) instruction.

[0118] For example, Figure 5As shown, the target lock is a high-performance spin lock, which is stored in a second memory area. The second memory area stores a loop array corresponding to the high-performance spin lock. The loop array includes at least one array element, which is located in a continuous physical address space. The at least one array element corresponds one-to-one with at least one thread that has applied to occupy the high-performance spin lock. The previous array element in the at least one array element points to the next array element, which indicates whether the corresponding thread has occupied the high-performance spin lock.

[0119] In some embodiments, each array element includes a first variable and a second variable, the first variable indicates whether the corresponding thread has occupied the high-performance spin lock, and the second variable indicates the physical address of the next array. For example, when the thread occupies the high-performance spin lock, the value of the first variable is 1, and when the thread does not occupy the high-performance spin lock, the value of the first variable is 0. That is, the value of the first variable in at most one array element of the at least one array element is 1, and the value of the first variable in the other numerical elements is 0. Wherein, in Figure 5 In the example, the value of the first variable in the array element corresponding to processor 0 is 1, and the value of the first variable in the array elements corresponding to other processors is 0. Moreover, after a thread releases the high-performance spin lock, the value of the first variable in the next array element can be set to 1 based on the physical address indicated by the second variable in the array element corresponding to the thread, thereby indicating that the thread corresponding to the next array element occupies the high-performance spin lock.

[0120] Since the at least one array element is located in a continuous physical address space, and a continuous physical address space is usually located in the same page table, when the value of the first variable in the previous array element is updated based on the physical address indicated by the second variable in the previous array element, an address conversion can be performed through the mapping relationship between the virtual address and the physical address of this page table. In this way, there is no need to perform address conversion again for subsequent array elements.

[0121] In some embodiments, the size of each of the at least one array element is the same as the cache line size. Therefore, the array elements corresponding to each thread can not only be stored in the second memory area, but also cached in the local cache of the processor. This can avoid frequent access to shared memory and cache synchronization operations caused by different processors accessing the same array elements.

[0122] In the case where the second type of lock includes a high-performance spin lock, the high-performance spin lock is not only stored in the second memory area, but may also be stored in the processor's cache. In the case where the high-performance lock is stored in the processor's cache, the high-performance spin lock cached by each processor can be called a private lock, that is, each processor cache has its own corresponding array element, and each corresponding array element indicates the occupancy of its own private lock. Each processor determines whether the high-performance spin lock is currently occupied by accessing its own private lock, without having to access the second memory area to determine whether the high-performance spin lock is currently occupied, thereby avoiding frequent access to shared memory. For example, if Figure 5 As shown, processor 0 currently owns the high-performance spin lock, and processors 1 and 2 store their corresponding array elements in their caches. Processors 1 and 2 determine whether the high-performance spin lock is currently occupied by accessing their respective private locks.

[0123] The above description uses the shared resources of multiple processors as an example. In actual applications, some shared resources may not be shared by multiple processors, but rather by different cores within the same processor. In this case, the lock corresponding to the shared resource can be stored in shared memory or in the processor's memory. In other words, for shared resources between different cores within the same processor, the lock corresponding to these shared resources can be stored in shared memory or in the processor's memory, providing greater flexibility.

[0124] In the embodiment of the present application, the locks corresponding to the shared resources of the multiple processors are stored in shared memory, rather than in the memory of the processors. Thus, the multiple processors can determine whether the locks corresponding to the shared resources are occupied by accessing the shared memory, without having to access the memory of a particular processor. This prevents the locks corresponding to the shared resources from migrating between the caches or memories of different processors, and also avoids the problem of a large number of synchronization messages caused by maintaining cache coherence, thereby improving application performance.

[0125] In addition, since the shared memory is the memory of a shared device outside the multiple processors and not the memory of a certain processor, the latency for each processor to access the shared memory is basically the same. Therefore, using the shared memory to store the locks corresponding to the shared resources can also avoid the problem of asymmetric memory access latency caused by the CC-NUMA architecture, thereby avoiding the problem of unfairness in the occupation of locks corresponding to shared resources by threads on different processors.

[0126] Furthermore, when the shared memory includes a first memory area and a second memory area, since the first type of lock cannot be cached by the multiple processors, the first type of lock is stored in the first memory area rather than in the processor's memory. This ensures that the latency for the processor to access the first type of lock is roughly the same as the latency for accessing the local LLC, which is lower than the latency for accessing local memory and improves the processing speed of lock requests. Since the second type of lock can be cached by the multiple processors, the second type of lock is stored in the second memory area and can also be cached in each corresponding processor, thus preventing high-performance locks from occupying the local memory resources of each processor.

[0127] Figure 6 This is a structural diagram of a lock request processing device provided by an embodiment of the present application. The device can be implemented by software, hardware, or a combination of both to become part or all of the processors in a CC-NUMA server. The CC-NUMA server can be as follows Figure 1 The CC-NUMA server includes multiple processors and a shared device, the shared device includes a shared memory, the shared memory is used to store locks corresponding to the shared resources of the multiple processors, and the device is included in any processor of the multiple processors, see Figure 6 The device includes: a request receiving module 601, an occupancy determination module 602 and a request processing module 603.

[0128] The request receiving module 601 is configured to receive a lock request from a target thread. The lock request is used to request the occupation of a target lock, where the target lock is a lock corresponding to a target resource, which is any resource shared by the multiple processors. For detailed implementation, please refer to the relevant content in the above embodiment and will not be repeated here.

[0129] The occupancy determination module 602 is used to determine the occupancy of the target lock from the shared memory, and the occupancy indicates whether the target lock is currently occupied. For detailed implementation process, please refer to the relevant content of the above embodiment, which will not be repeated here.

[0130] The request processing module 603 is used to process the lock request based on the occupancy status. For the detailed implementation process, please refer to the relevant content in the above embodiment, which will not be repeated here.

[0131] Optionally, the occupancy determination module 602 is specifically configured to:

[0132] Get the user-mode virtual address of the target lock;

[0133] Based on the user-state virtual address of the target lock, the kernel-state virtual address of the target lock is determined through the mapping relationship between the user-state virtual address space and the kernel-state virtual address space of the shared memory;

[0134] Based on the kernel-state virtual address of the target lock, the physical address of the target lock in the shared memory is determined through the mapping relationship between the kernel-state virtual address space and the physical address space of the shared memory;

[0135] Based on the physical address of the target lock in the shared memory, the occupancy of the target lock is determined from the shared memory.

[0136] Optionally, the occupancy determination module 602 is further specifically configured to:

[0137] Determine the size of the shared memory from the configuration space corresponding to the shared device;

[0138] Based on the size of the shared memory, allocate kernel-mode virtual address space for the shared memory and establish a mapping relationship between the physical address space of the shared memory and the kernel-mode virtual address space;

[0139] Based on the kernel-mode virtual address space allocated for the shared memory, the user-mode virtual address space of the shared memory is determined, and a mapping relationship between the kernel-mode virtual address space and the user-mode virtual address space is established.

[0140] Optionally, the shared memory includes a first memory area and a second memory area, the first memory area is used to store a first type of lock, and the second memory area is used to store a second type of lock. The first type of lock does not allow caching by multiple processors, and the second type of lock allows caching by multiple processors. The occupancy determination module 602 is specifically used to:

[0141] If the target lock belongs to the first type of lock, determining the occupancy of the target lock from the first memory area;

[0142] If the target lock belongs to the second type of lock and the target lock does not exist in the cache of the processor corresponding to the target thread, the occupancy status of the target lock is determined from the second memory area.

[0143] Optionally, the device further comprises:

[0144] A configuration information acquisition module, configured to acquire configuration information of the shared memory from a configuration space corresponding to the shared device, the configuration information including the size of the first memory area and the size of the second memory area;

[0145] A memory partitioning module, configured to partition the shared memory into a first memory area and a second memory area based on configuration information of the shared memory;

[0146] The attribute setting module is used to set the cache attribute of the first memory area and the cache attribute of the second memory area, and the cache attribute indicates whether the lock stored in the corresponding memory area is allowed to be cached by multiple processors.

[0147] In the embodiment of the present application, the locks corresponding to the shared resources of the multiple processors are stored in shared memory, rather than in the memory of the processors. Thus, the multiple processors can determine whether the locks corresponding to the shared resources are occupied by accessing the shared memory, without having to access the memory of a particular processor. This prevents the locks corresponding to the shared resources from migrating between the caches or memories of different processors, and also avoids the problem of a large number of synchronization messages caused by maintaining cache coherence, thereby improving application performance.

[0148] In addition, since the shared memory is the memory of a shared device outside the multiple processors and not the memory of a certain processor, the latency for each processor to access the shared memory is basically the same. Therefore, using the shared memory to store the locks corresponding to the shared resources can also avoid the problem of asymmetric memory access latency caused by the CC-NUMA architecture, thereby avoiding the problem of unfairness in the occupation of locks corresponding to shared resources by threads on different processors.

[0149] It should be noted that the above embodiments illustrate the division of the functional modules into the aforementioned functional modules when processing lock requests. In actual applications, the aforementioned functions can be assigned to different functional modules as needed, i.e., the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. Furthermore, the device and the lock request processing method embodiments provided in the above embodiments are based on the same concept. The specific implementation process is detailed in the method embodiments and will not be repeated here.

[0150] In the above embodiments, all or part of the embodiments can be implemented by software, hardware, firmware, or any combination thereof. When implemented using software, all or part of the embodiments can be implemented in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of the present application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via a wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) method. The computer-readable storage medium can be any available medium that can be accessed by a computer, or a data storage device such as a server or data center that includes one or more available media integrated therein. The available medium may be a magnetic medium (e.g., a floppy disk, a hard disk, or a magnetic tape), an optical medium (e.g., a digital versatile disc (DVD)), or a semiconductor medium (e.g., a solid state disk (SSD)). It is worth noting that the computer-readable storage medium mentioned in the embodiments of the present application may be a non-volatile storage medium, in other words, a non-transient storage medium.

[0151] It should be understood that the "plurality" mentioned herein refers to two or more. In the description of the embodiments of the present application, unless otherwise specified, " / " means or, for example, A / B can mean A or B; "and / or" in this article is merely a description of the association relationship of associated objects, indicating that there can be three relationships, for example, A and / or B can mean: A exists alone, A and B exist at the same time, and B exists alone. In addition, in order to facilitate a clear description of the technical solutions of the embodiments of the present application, in the embodiments of the present application, words such as "first" and "second" are used to distinguish between identical or similar items with substantially the same functions and effects. Those skilled in the art will understand that words such as "first" and "second" do not limit the quantity and execution order, and words such as "first" and "second" do not necessarily limit them to be different.

[0152] It should be noted that the information (including but not limited to user device information, user personal information, etc.), data (including but not limited to data used for analysis, stored data, displayed data, etc.) and signals involved in the embodiments of this application are all authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data need to comply with the relevant laws, regulations and standards of relevant countries and regions.

[0153] The above description is an embodiment provided for this application and is not intended to limit this application. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of this application should be included in the scope of protection of this application.

Claims

1. A server, characterized in that: The server includes multiple processors and a shared device, the multiple processors are connected to each other via a CC-NUMA bus, and the multiple processors are respectively connected to the shared device via a CC-NUMA bus; Each of the plurality of processors has a cache and a memory, the sharing device has a shared memory, and the shared memory is used to store locks corresponding to shared resources of the plurality of processors; Wherein, the shared memory stores a loop array corresponding to a high-performance spin lock, the loop array includes at least one array element, the at least one array element corresponds one-to-one to at least one thread applying to occupy the high-performance spin lock, the previous array element in the at least one array element points to the next array element, the array element indicates whether the corresponding thread has occupied the high-performance spin lock, and when the thread corresponding to the previous array element releases the high-performance spin lock, the thread corresponding to the next array element pointed to by the previous array element occupies the high-performance spin lock, and the high-performance spin lock includes an MCS lock.

2. The server according to claim 1, wherein The shared memory and the memories of the multiple processors are globally and uniformly addressed.

3. The server according to claim 1 or 2, wherein: The shared memory includes a first memory area and a second memory area, the first memory area is used to store a first type of lock, and the second memory area is used to store a second type of lock. The first type of lock is not allowed to be cached by the multiple processors, and the second type of lock is allowed to be cached by the multiple processors.

4. The server according to claim 3, wherein: The first type of locks includes mutual exclusion locks and basic spin locks, and the second type of locks includes the high-performance spin locks.

5. The server according to claim 4, wherein: The second memory area stores a loop array corresponding to the high-performance spin lock, and the at least one array element is located in a continuous physical address space.

6. The server according to claim 1, wherein: A size of each of the at least one array element is the same as a size of a cache line in caches of the plurality of processors.

7. The server according to any one of claims 1 to 6, wherein: The CC-NUMA bus supports memory semantic access.

8. A method for processing a lock request in a server, characterized in that: The server includes multiple processors and a shared device, the multiple processors are connected to each other via a CC-NUMA bus, the multiple processors are respectively connected to the shared device via the CC-NUMA bus, the shared device includes a shared memory, and the shared memory is used to store locks corresponding to shared resources of the multiple processors. The method includes: Receive a lock request sent by a target thread, where the lock request is used to request to occupy a target lock, where the target lock is a lock corresponding to a target resource, and where the target resource is any resource shared by the multiple processors; Determining an occupancy status of the target lock from the shared memory, wherein the occupancy status indicates whether the target lock is currently occupied; Processing the lock request based on the occupancy status; Wherein, the shared memory stores a loop array corresponding to a high-performance spin lock, the loop array includes at least one array element, the at least one array element corresponds one-to-one to at least one thread applying to occupy the high-performance spin lock, the previous array element in the at least one array element points to the next array element, the array element indicates whether the corresponding thread has occupied the high-performance spin lock, and when the thread corresponding to the previous array element releases the high-performance spin lock, the thread corresponding to the next array element pointed to by the previous array element occupies the high-performance spin lock, and the high-performance spin lock includes an MCS lock.

9. The method according to claim 8, wherein Determining the occupancy of the target lock from the shared memory includes: Obtaining the user-mode virtual address of the target lock; Based on the user-state virtual address of the target lock, determining the kernel-state virtual address of the target lock through a mapping relationship between the user-state virtual address space and the kernel-state virtual address space of the shared memory; Based on the kernel-state virtual address of the target lock, determining the physical address of the target lock in the shared memory through a mapping relationship between the kernel-state virtual address space and the physical address space of the shared memory; Based on the physical address, the occupancy status of the target lock is determined from the shared memory.

10. The method according to claim 9, wherein Before determining the occupancy status of the target lock from the shared memory, the method further includes: determining the size of the shared memory from a configuration space corresponding to the shared device; Based on the size of the shared memory, allocating a kernel-mode virtual address space to the shared memory, and establishing a mapping relationship between the physical address space of the shared memory and the kernel-mode virtual address space; Based on the kernel-mode virtual address space, the user-mode virtual address space of the shared memory is determined, and a mapping relationship between the kernel-mode virtual address space and the user-mode virtual address space is established.

11. The method according to any one of claims 8 to 10, characterized in that: The shared memory includes a first memory area and a second memory area, the first memory area is used to store a first type of lock, the second memory area is used to store a second type of lock, the first type of lock is not allowed to be cached by the multiple processors, and the second type of lock is allowed to be cached by the multiple processors; Determining the occupancy of the target lock from the shared memory includes: If the target lock belongs to the first type of lock, determining the occupancy of the target lock from the first memory area; If the target lock belongs to the second type of lock and the target lock does not exist in the cache of the processor corresponding to the target thread, the occupancy status of the target lock is determined from the second memory area.

12. The method according to claim 11, wherein Before determining the occupancy status of the target lock from the shared memory, the method further includes: Acquire configuration information of the shared memory from a configuration space corresponding to the shared device, the configuration information including a size of the first memory area and a size of the second memory area; Based on the configuration information of the shared memory, dividing the shared memory into a first memory area and a second memory area; A cache attribute of the first memory area and a cache attribute of the second memory area are set, where the cache attribute indicates whether locks stored in corresponding memory areas are allowed to be cached by the multiple processors.

13. A lock request processing device in a server, characterized in that: The server includes multiple processors and a shared device, wherein the multiple processors are connected to each other via a CC-NUMA bus, and the multiple processors are respectively connected to the shared device via the CC-NUMA bus. The shared device includes a shared memory, and the shared memory is used to store locks corresponding to shared resources of the multiple processors. The device includes: a request receiving module, configured to receive a lock request sent by a target thread, wherein the lock request is used to request to occupy a target lock, wherein the target lock is a lock corresponding to a target resource, and the target resource is any resource shared by the multiple processors; an occupancy status determining module, configured to determine an occupancy status of the target lock from the shared memory, wherein the occupancy status indicates whether the target lock is currently occupied; A request processing module, configured to process the lock request based on the occupancy status; Wherein, the shared memory stores a loop array corresponding to a high-performance spin lock, the loop array includes at least one array element, the at least one array element corresponds one-to-one to at least one thread applying to occupy the high-performance spin lock, the previous array element in the at least one array element points to the next array element, the array element indicates whether the corresponding thread has occupied the high-performance spin lock, and when the thread corresponding to the previous array element releases the high-performance spin lock, the thread corresponding to the next array element pointed to by the previous array element occupies the high-performance spin lock, and the high-performance spin lock includes an MCS lock.

14. The device according to claim 13, wherein The occupancy determination module is specifically configured to: Obtaining the user-mode virtual address of the target lock; Based on the user-state virtual address of the target lock, determining the kernel-state virtual address of the target lock through a mapping relationship between the user-state virtual address space and the kernel-state virtual address space of the shared memory; Based on the kernel-state virtual address of the target lock, determining the physical address of the target lock in the shared memory through a mapping relationship between the kernel-state virtual address space and the physical address space of the shared memory; Based on the physical address, the occupancy status of the target lock is determined from the shared memory.

15. The device according to claim 14, wherein The occupancy determination module is further specifically configured to: determining the size of the shared memory from a configuration space corresponding to the shared device; Based on the size of the shared memory, allocating a kernel-mode virtual address space to the shared memory, and establishing a mapping relationship between the physical address space of the shared memory and the kernel-mode virtual address space; Based on the kernel-mode virtual address space, the user-mode virtual address space of the shared memory is determined, and a mapping relationship between the kernel-mode virtual address space and the user-mode virtual address space is established.

16. The device according to any one of claims 13 to 15, characterized in that: The shared memory includes a first memory area and a second memory area, the first memory area is used to store a first type of lock, the second memory area is used to store a second type of lock, the first type of lock is not allowed to be cached by the multiple processors, and the second type of lock is allowed to be cached by the multiple processors; The occupancy determination module is specifically configured to: If the target lock belongs to the first type of lock, determining the occupancy of the target lock from the first memory area; If the target lock belongs to the second type of lock and the target lock does not exist in the cache of the processor corresponding to the target thread, the occupancy status of the target lock is determined from the second memory area.

17. The device according to claim 16, wherein The device further comprises: a configuration information acquisition module, configured to acquire configuration information of the shared memory from a configuration space corresponding to the shared device, the configuration information including the size of the first memory area and the size of the second memory area; A memory partitioning module, configured to partition the shared memory into a first memory area and a second memory area based on configuration information of the shared memory; The attribute setting module is used to set a cache attribute of the first memory area and a cache attribute of the second memory area, wherein the cache attribute indicates whether the lock stored in the corresponding memory area is allowed to be cached by the multiple processors.

18. A computer-readable storage medium, characterized in that The storage medium stores instructions, and when the instructions are executed on the computer, the computer is caused to execute the steps of any one of the methods of claims 8 to 12.

Images