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

Abstract

The invention discloses a CC-NUMA server, a lock request processing method and a related device, and belongs to the field of computers. The CC-NUMA server comprises a plurality of processors and a sharing device, the plurality of processors are connected through a CC-NUMA bus, and the plurality of processors are also respectively connected with the sharing device through the CC-NUMA bus; each processor is provided with a cache and a memory, the sharing device is provided with a shared memory, and the shared memory is used for storing locks corresponding to shared resources of the processors. In the application, the plurality of processors can determine whether the lock corresponding to the shared resource is occupied by accessing the shared memory instead of accessing the memory of a certain processor, so that the lock corresponding to the shared resource is prevented from being migrated between caches or memories of different processors, and the memory utilization rate of the shared resource is improved. And moreover, the problem that a large number of synchronous messages are caused by keeping cache consistency can be avoided, and the application performance is improved.

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 contents of the original application are 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 usually includes multiple processors interconnected by a low-latency bus, and each processor has a cache and memory. Each processor can not only access local memory, but also access the memory of other processors, i.e., remote memory, through a low-latency bus, and these processors can also maintain cache consistency between each processor through a cache consistency 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 state 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] The present application provides a CC-NUMA server, a lock request processing method and a related device, which can avoid the lock corresponding to the shared resource from being migrated between the cache or memory 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, wherein the CC-NUMA 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 also respectively connected to the shared device via the CC-NUMA bus; each of the multiple processors has a cache and a memory, and the shared device has a shared memory, and the shared memory is used to store locks corresponding to shared resources of the multiple processors.

[0007] The present application stores the locks corresponding to the shared resources of the multiple processors through shared memory, rather than through the memory of the processor. In this way, 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 certain processor to determine whether the locks corresponding to the shared resources are occupied, 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.

[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 the processor to access the shared memory.

[0010] 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, 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. 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 need to maintain cache consistency 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 mutex lock and a basic spin lock, and the second type of lock includes a high-performance spin lock. The basic spin lock may also be referred to as a simple spin lock or a first spin lock, such as a spin lock, and the high-performance spin lock includes an MCS lock, which may also be referred to as a second spin lock, and 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 array element in the at least one array element is the same as the size of a cache line in the cache of the multiple processors. Therefore, the array element corresponding to each thread can not only be stored in the second memory area, but also be cached in the local cache of the processor, so that frequent access to the shared memory can be avoided, and cache synchronization operations caused by different processors accessing the same array element can be avoided.

[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 the present 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, 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, the shared memory is used to store locks corresponding to shared resources of the multiple processors, and 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] The present application stores the locks corresponding to the shared resources of the multiple processors through shared memory, rather than through the memory of the processor. In this way, 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 certain processor to determine whether the locks corresponding to the shared resources are occupied, 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.

[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 to occupy 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 to request that the access rights to the target resource be assigned to the target thread. The access rights include read permission and write permission.

[0021] In some implementations, determining the occupancy status of the target lock from the shared memory includes: obtaining a user-state 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 a user-state virtual address space and a 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; and based on the physical address, determining the occupancy status of the target lock from the shared memory.

[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, and 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 the resource identifier and the user-state virtual address. In this way, after receiving the lock request, the corresponding user-state virtual address can be obtained from the corresponding relationship between the stored resource identifier and the user-state virtual address 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 application in the user space cannot directly access the kernel space. Therefore, before determining the occupancy of the target lock from the shared memory, it also includes: determining the size of the shared memory from the configuration space corresponding to the shared device; allocating a kernel state 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 state virtual address space; determining the user state virtual address space of the shared memory based on the kernel state virtual address space, and establishing a mapping relationship between the kernel state virtual address space and the user state virtual address space. In this way, after determining the user state 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 state virtual address space, the kernel state virtual address space and the physical address space of the shared memory, and then 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.

[0025] 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, 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. 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, and the second type of lock allows the multiple processors to cache, the first type of lock can only be stored in the first memory area, and 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 directly determined 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 directly determined 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 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 a first memory area and a second memory area; 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 the target resource access rights are not allocated to the target thread. If the target lock is not currently occupied, it is determined that no thread currently has access rights to the target resource, and the target resource access rights are allocated 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, the target thread is awakened from the sleep state, and execution is resumed. 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, in order to avoid the basic spin lock being read frequently, when the processor determines that the basic spin lock is currently occupied, a low-power instruction can 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 being awakened. For example, the low-power instruction can be a Pause instruction or a wait for event (WFE) instruction.

[0031] 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, which includes at least one array element, which is located in a continuous physical address space, and the at least one array element corresponds to at least one thread that applies 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.

[0032] In some implementations, each array element includes a first variable and a second variable, the first variable indicating whether the corresponding thread has occupied the high-performance spin lock, and the second variable indicating 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.

[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, for subsequent array elements, there is no need to perform address conversion again.

[0034] In some implementations, the size of each array element in 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 be cached in the local cache of the processor, so that frequent access to the shared memory can be avoided, and cache synchronization operations caused by different processors accessing the same array element can be avoided.

[0035] 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 cache of the processor. In the case where the high-performance lock is stored in the cache of the processor, 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 the corresponding array element indicates the occupancy of the respective private lock. Each processor determines whether the high-performance spin lock is currently occupied by accessing its own private lock, without having to determine whether the high-performance spin lock is currently occupied by accessing the second memory area, 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 behavior in the second aspect. The device includes at least one module, and the at least one module is used to implement the method provided in the second aspect.

[0037] In a fourth aspect, a CC-NUMA server is provided, the CC-NUMA server comprising a processor and a memory, the memory being used 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, and 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, and when the instructions are executed on a computer, the computer executes the steps of the method described in the second aspect. In other words, a computer program is provided, and when the computer program is executed on a computer, the computer executes 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 It is a structural diagram of a CC-NUMA server provided in an embodiment of the present application;

[0043] Figure 2It 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 is a flowchart of a method for processing a lock request provided by an embodiment of the present application;

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

[0046] Figure 5 It is a 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 in conjunction with the accompanying drawings.

[0049] Before explaining in detail the CC-NUMA server and the method for processing lock requests 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 NUMA architecture, each processor has corresponding memory. Each processor can access not only its own memory but also the memory of other processors. For any one of the multiple processors, the processor is relatively close to its own memory, and its own memory is usually called local memory. The processor is relatively far from the memory of other processors, and the memory of other processors is usually called remote memory or non-local memory.

[0053] NUMA technology is a memory access architecture design for multi-processors. In a multi-processor system based on NUMA architecture, the memory access time depends on the relative position between the processor and the memory. That is, the 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] Cache is hardware that caches data in memory. Cache line is the basic unit of cache. Cache line size refers to the data size of a cache line. When the processor accesses the memory, it copies the data in the memory to the cache in units of cache line size. For example, the cache line size is N bytes. When the processor accesses the memory, it copies at least N bytes of data in the memory to the cache at a time. For example, the cache line size is usually 64Bytes.

[0058] 4. Critical Area

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

[0060] 5. Semaphore

[0061] Semaphores, sometimes called semaphores, are a mechanism used in a multithreaded environment to ensure that two or more threads cannot call the same shared resource at the same time. Before accessing a shared resource, a thread must acquire a semaphore, and once it has completed accessing the shared resource, the thread must release the semaphore. Other threads that want to access the shared resource must wait until the previous thread releases the semaphore. In other words, semaphores are used to coordinate various threads to ensure that they can use shared resources correctly and reasonably.

[0062] In abstract terms, a semaphore controls access to shared resources through a counter. The value of a 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 that attempt 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 count of the semaphore is greater than 0, the thread obtains a pass, which will cause the count of the semaphore to decrease. Otherwise, the thread will block until it obtains a pass. When the thread no longer needs to access the shared resource, the pass is released, which causes the count of the semaphore to increase. If another thread is waiting for a pass, the thread will obtain a pass.

[0063] 6. Mutex

[0064] A mutex lock means that only one visitor is allowed to access a resource at the same time, which is unique and exclusive. However, a mutex lock cannot limit the order in which visitors access resources, that is, the access is unordered.

[0065] Before a thread accesses a shared resource, it can apply for a mutex lock. If the mutex lock is already occupied by another thread, the thread will enter a blocked state, i.e., a sleeping state. The thread will be awakened from the blocked state only after the mutex lock is released.

[0066] 7. Spinlock

[0067] Spin locks are similar to mutex locks, and they are both used to solve the mutual exclusion of a resource. Whether it is a mutex lock or a spin lock, there can be at most one holder at any time, that is, at most one thread can obtain the lock at any time. However, the two have slightly different scheduling mechanisms. For a mutex lock, if the mutex lock is already occupied, the thread can only go to sleep. However, a spin lock will not cause the thread to sleep. If the spin lock is already occupied by other threads, the thread will keep looping there until the other thread releases the spin lock.

[0068] Secondly, the implementation environment involved in the embodiments of the present application is introduced.

[0069] A CC-NUMA server usually includes multiple processors interconnected by a low-latency bus, and each processor has a cache and memory. Each processor can not only access local memory, but also access the memory of other processors, i.e., remote memory, through a low-latency bus, and these processors can also maintain cache consistency between each processor through a cache consistency protocol.

[0070] The multiple processors have a large number of shared resources, such as last level cache (LLC), memory, input / output (IO) devices, etc. However, the access control of these shared resources by multi-core multi-threaded applications needs to ensure that they can only be used by a single thread at any time. When the thread enters the critical section, multiple threads must access the shared resources mutually exclusively. In order to ensure that the shared resources accessed in the critical section code are obtained and used mutually exclusively, and to avoid different threads accessing the same resources at the same time, it is necessary to introduce "lock" mechanisms such as semaphores, mutex locks, and spin locks, and ensure atomic operations on lock variables 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 lock 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 a great waste of processor resources.

[0072] With the continuous development of chip technology, more and more cores are integrated in the processor, and the performance of locks, especially the performance of global shared locks of multiple processors, is becoming more and more 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, the embodiment of the present application provides a CC-NUMA server and a method for processing lock requests, which 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 a plurality of processors 101 ( Figure 1 The multiple processors 101 are connected via a CC-NUMA bus ( Figure 1 The multiple processors 101 are also connected to the shared device 102 through a CC-NUMA bus. Each processor 101 in the multiple processors 101 has a cache and a memory. The shared device 102 includes a shared memory, which is used to store locks corresponding to the shared resources of the multiple processors 101.

[0074] The embodiment of the present application stores the locks corresponding to the shared resources of the multiple processors through shared memory, rather than through the memory of the processor. In this way, 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.

[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 may be 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 above-mentioned PLD may be a complex programmable logic device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL) or any combination thereof. Moreover, the processor 101 may be a single-core processor or a multi-core processor.

[0077] The shared device 102 may be a CPU, a data processing unit (DPU), or other devices with processing functions. In some embodiments, the shared device 102 may be referred to as an xPU. The shared memory may be a portion of the memory of the shared device 102, and the shared memory may be set to be invisible to the software of the shared device 102. That is, when the shared device 102 is started, the software system of the shared device is not informed of the shared memory.

[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 the 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 processor 101 accesses its own local memory, it usually accesses it at the granularity of cache lines. That is to say, the data size of the local memory accessed by processor 101 is usually the same as the cache line size. This method of accessing memory at the granularity of cache lines in a synchronous manner can be called memory semantic access. However, for shared device 102, when processor 101 accesses the memory of 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, shared device 102 supports memory semantic access, and connects processor 101 and shared device 102 through a CC-NUMA bus, thereby supporting processor 101 to access the shared memory of shared device 102 in a memory semantic manner, thereby reducing the latency of processor 101 accessing shared memory.

[0080] Based on the above description, the shared memory is invisible to the software system of the shared device 102 , so 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 a 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 is not limited in the embodiments of the present application.

[0082] The memory of the processor 101 may exist independently and be 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 memory 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, 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.

[0085] For example, please refer to Figure 2 The kernel driver of the shared device is installed in the operating system kernel of the CC-NUMA server. The kernel driver is used to 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. Moreover, the kernel driver can also generate an IOCTL user-mode interface for the shared device. In this way, the application in the user space can allocate user-mode virtual address space for the shared memory through the IOCTL user-mode interface and establish a mapping relationship between the kernel-mode virtual address space of the shared memory 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 size of the shared memory is stored in the configuration space of the sharing device 102, so the processor 101 can directly obtain the size of the shared memory from the configuration space of the sharing device 102. Moreover, the shared memory is usually located in the kernel space, and the application in the user space cannot directly access the memory in the kernel space. Therefore, after obtaining the size of the shared memory, the kernel state virtual address space can be allocated to 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 state virtual address space can be established, and then the user state virtual address space corresponding to the kernel state virtual address space of the shared memory can be determined, and a mapping relationship between the kernel state virtual address space of the shared memory and the user state virtual address space can be established. In this way, the application in the user space can access the shared memory through the mapping relationship between the user state virtual address space, the kernel state virtual address space and the physical address space.

[0088] During the system startup phase, the CC-NUMA server can poll the configuration space of each peripheral component interconnect express (PCIe) device, thereby allocating address space to each PCIe device in the addressing space. Therefore, in an 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 the shared memory and the processor's memory are globally and uniformly addressed, by estimating the latency of the processor accessing the shared memory with memory semantics, it is found that the latency of the processor accessing the shared memory is basically the same as the latency of the processor accessing its own LLC. For example, assuming that the shared memory is a static random access memory (SRAM) type memory, it is estimated that the latency of the processor accessing the SRAM memory is about 15ns, and the latency of the processor accessing its own LLC is also basically about 15ns. Since the latency of the processor accessing the shared memory is the same as the latency of accessing the LLC, the lock corresponding to the shared resource is stored in the shared memory, and the application performance is basically not affected.

[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 the first type of locks, the second memory area is used to store the second type of locks, the first type of locks are not allowed to be cached by the multiple processors 101, and the second type of 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, configuration information of a shared memory is obtained from a configuration space of a shared device, and based on the configuration information of the shared memory, the shared memory is divided into a first memory area and a second memory area, wherein the configuration information of the shared memory includes the size of the first memory area and the size of the second memory area. Then, a cache attribute of the first memory area and a cache attribute of the second memory area are set, wherein the cache attribute indicates whether a lock stored in a corresponding memory area is 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 need to maintain cache consistency 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 a mutex lock and a basic spin lock, and the second type of lock includes a high-performance spin lock. The basic spin lock can also be called a simple spin lock, such as the above-mentioned Spinlock, and the high-performance spin lock includes an MCS lock. Among them, the MCS in the MCS lock refers to Mellor Crummey Scott, which are 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 array element in the at least one array element is the same as the size of a cache line in the cache of the multiple processors. Therefore, the array element corresponding to each thread can not only be stored in the second memory area, but also be cached in the local cache of the processor, so that frequent access to the shared memory can be avoided, and cache synchronization operations caused by different processors accessing the same array element can be avoided.

[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. Among them, 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, etc.

[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 a variety of 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 a variety of ways. For example, the input device can be a mouse, a keyboard, a touch screen device, or a 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 comprises 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 to occupy 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 the 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 embodiments 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, a 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, a 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 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, and 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 the resource identifier and the user-state virtual address. In this way, after receiving the lock request, the corresponding user-state virtual address can be obtained from the corresponding relationship between the stored resource identifier and the user-state virtual address 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.

[0107] Since the shared memory is located in the kernel space and the target thread is located in the user space, the application in the user space 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 state 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 state virtual address space, determining the user state virtual address space of the shared memory based on the kernel state virtual address space of the shared memory, and establishing a mapping relationship between the kernel state virtual address space of the shared memory and the user state virtual address space. In this way, after determining the user state 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 state virtual address space, the kernel state virtual address space and the 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.

[0108] In some embodiments, 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. In this case, the implementation 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, then 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, then 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, and the second type of lock allows the multiple processors to cache, the first type of lock can only be stored in the first memory area, and 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 directly determined 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 directly determined 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 above description, the latency of a processor accessing shared memory is roughly the same as the latency of accessing its own LLC. However, the latency of a processor accessing its own LLC is usually less than the latency of accessing its own memory. Therefore, storing the locks corresponding to shared resources in shared memory can improve the processing efficiency of lock requests compared to storing the locks of shared resources in the processor's memory. For example, the latency of a processor accessing its own memory is 80ns.

[0111] In some embodiments, the first type of lock includes a mutex lock and a basic spin lock, and the second type of lock includes a high-performance spin lock. Of course, in practical 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 includes a semaphore, which is not limited in the embodiments 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, dividing the shared memory into the first memory area and the second memory area based on the configuration information of the shared memory, 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 the target resource access rights are not allocated to the target thread. If the target lock is not currently occupied, it is determined that no thread currently has access rights to the target resource, and the target resource access rights are allocated to the target thread.

[0116] For example, Figure 4 As shown, the target lock is a mutex lock or a basic spin lock, and the mutex lock and the basic spin lock are both 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, the target thread is awakened from the sleep state, and execution is resumed. 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.

[0117] In some embodiments, in order to avoid the basic spin lock being read frequently, when the processor determines that the basic spin lock is currently occupied, a low-power instruction can 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 being awakened. For example, the low-power instruction can 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 the second memory area. The second memory area stores a loop array corresponding to the high-performance spin lock, and the loop array includes at least one array element, and the at least one array element is located in a continuous physical address space. The at least one array element corresponds to at least one thread that applies 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.

[0119] In some embodiments, each array element includes a first variable and a second variable, the first variable indicating whether the corresponding thread has occupied the high-performance spin lock, and the second variable indicating 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, at most only one of the at least one array element has a value of 1 for the first variable, and the values ​​of the first variables in the other numerical elements are 0. 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, for subsequent array elements, there is no need to perform address conversion again.

[0121] In some embodiments, the size of each array element in 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 be cached in the local cache of the processor, so that frequent access to the shared memory can be avoided, and cache synchronization operations caused by different processors accessing the same array element can be avoided.

[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 processor 1 and processor 2 store their corresponding array elements in their caches. Processor 1 and processor 2 determine whether the high-performance spin lock is currently occupied by accessing their respective private locks.

[0123] The above is an introduction using the shared resources of the multiple processors as an example. In actual applications, some shared resources may not be shared by the multiple processors, but by different cores in the same processor. In this case, the lock corresponding to the shared resource can be stored in the shared memory or in the processor's memory. In other words, for the shared resources of different cores in the same processor, the locks corresponding to these shared resources can be stored in the shared memory or in the processor's memory, which is more flexible.

[0124] The embodiment of the present application stores the locks corresponding to the shared resources of the multiple processors through shared memory, rather than through the memory of the processor. In this way, 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.

[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] Moreover, in the case where the shared memory includes the first memory area and the second memory area, since the first type of lock is not allowed to be cached by the multiple processors, the first type of lock is stored in the first memory area instead of in the processor's memory, so that the latency of the processor accessing the first type of lock is basically the same as the latency of accessing the local LLC, which is lower than the latency of accessing the local memory, thereby improving the processing speed of the lock request. Since the second type of lock is allowed to be cached by the multiple processors, the second type of lock is stored in the second memory area, and the second type of lock can also be cached in the respective corresponding processors, so that high-performance locks can be prevented from occupying the local memory resources of each processor.

[0127] Figure 6 is a structural diagram of a lock request processing device provided in 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 processor 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 status determining module 602 and a request processing module 603.

[0128] The request receiving module 601 is used to receive a lock request sent by a target thread, and 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. For the detailed implementation process, please refer to the relevant content in the above embodiment, which 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 the detailed implementation process, please refer to the relevant content in 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. Please refer to the relevant content in the above embodiment for the detailed implementation process, 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-state virtual address space for the shared memory, and establish a mapping relationship between the physical address space of the shared memory and the kernel-state 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, 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 multiple processors, and the second type of lock is allowed to be cached 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 of the target lock is determined from the second memory area.

[0143] Optionally, the device further comprises:

[0144] A configuration information acquisition module, used 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, used for partitioning the shared memory into a first memory area and a second memory area based on the 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] The embodiment of the present application stores the locks corresponding to the shared resources of the multiple processors through shared memory, rather than through the memory of the processor. In this way, 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.

[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: when the device provided in the above embodiment processes the lock request, only the division of the above functional modules is used as an example. In actual application, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device is divided into different functional modules to complete all or part of the functions described above. In addition, the device provided in the above embodiment and the embodiment of the method for processing the lock request belong to the same concept. The specific implementation process is detailed in the method embodiment, which will not be repeated here.

[0150] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When implemented using software, it can be implemented in whole or in part 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, the process or function described in the embodiment of the present application is generated in whole or in part. 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 a website site, computer, server or data center by wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) mode to another website site, computer, server or data center. The computer-readable storage medium can be any available medium that a computer can access, or a data storage device such as a server or data center that includes one or more available media integrated. The available medium may be a magnetic medium (e.g., a floppy disk, a hard disk, 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 embodiment 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 "multiple" 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 only a description of the association relationship of the 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 the clear description of the technical solution of the embodiments of the present application, in the embodiments of the present application, the words "first", "second" and the like are used to distinguish between the same items or similar items with basically the same functions and effects. Those skilled in the art can understand that the words "first", "second" and the like do not limit the quantity and execution order, and the words "first", "second" and the like do not limit them to be necessarily 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 the present 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 relevant laws, regulations and standards of relevant countries and regions.

[0153] The above-mentioned embodiments are provided for the present application and are not intended to limit the present application. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present application shall be included in the protection scope of the present application.

Claims

1. A server, characterized in that: The server includes a plurality of processors and a shared device, the plurality of processors are connected to each other through a CC-NUMA bus, and the plurality of processors are respectively connected to the shared device through the CC-NUMA bus; Each of the multiple processors has a cache and a memory, and the sharing device has a shared memory, and the shared memory is used to store locks corresponding to shared resources of the multiple processors.

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

3. The server according to claim 1 or 2, 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.

4. The server according to claim 3, characterized in that The first type of locks include mutual exclusion locks and basic spin locks, and the second type of locks include high-performance spin locks.

5. The server according to claim 4, characterized in that 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.

6. The server according to claim 5, characterized in that 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 plurality of processors.

7. The server according to any one of claims 1 to 6, characterized in that: 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 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 comprises: 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 wherein 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; Based on the occupancy status, the lock request is processed.

9. The method according to claim 8, characterized in that Determining the occupancy of the target lock from the shared memory includes: Obtaining the user state virtual address of the target lock; 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; 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; 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, characterized in that 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; Based on the size of the shared memory, a kernel state virtual address space is allocated to the shared memory, and a mapping relationship between the physical address space of the shared memory and the kernel state virtual address space is established; 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, characterized in that Before determining the occupancy 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, wherein 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 a CC-NUMA bus, and the shared device includes a shared memory, and the shared memory is used to store locks corresponding to shared resources of the multiple processors, and the device is included in any processor among the multiple processors, and the device includes: A request receiving module, used for receiving a lock request sent by a target thread, wherein the lock request is used for requesting to occupy a target lock, wherein the target lock is a lock corresponding to a target resource, and wherein the target resource is any resource shared by the multiple processors; An occupancy determination module, used to determine the occupancy of the target lock from the shared memory, wherein the occupancy indicates whether the target lock is currently occupied; A request processing module is used to process the lock request based on the occupancy status.

14. The device according to claim 13, characterized in that The occupancy determination module is specifically used for: Obtaining the user state virtual address of the target lock; 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; 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; 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, characterized in that The occupancy determination module is further specifically used for: Determining the size of the shared memory from the configuration space corresponding to the shared device; Based on the size of the shared memory, a kernel state virtual address space is allocated to the shared memory, and a mapping relationship between the physical address space of the shared memory and the kernel state virtual address space is established; 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 used for: 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, characterized in that The device also includes: A configuration information acquisition module, used 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 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 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 executes the steps of any one of the methods of claims 8-12.

Images