IP Library Granted Patent US 10,360,150
Granted Patent B2
US 10,360,150 · App. 13/026,447 · Granted Jul 23, 2019

Techniques for managing memory in a multiprocessor architecture

View Patent ↗
Loading inventors, assignments & file history…
Monitor This Case
Get email alerts when status or documents change.
Order Certified Copies
Most orders are placed with the USPTO same day — all within 24 business hours.
Order via The Patent Place →
Pre-filled with this patent's details
Quick Facts
Patent No.
US 10,360,150
App. No.
13/026,447
Granted
Jul 23, 2019
Kind
B2
Abstract

Techniques for managing memory in a multiprocessor architecture are presented. Each processor of the multiprocessor architecture includes its own local memory. When data is to be removed from a particular local memory or written to storage that data is transitioned to another local memory associated with a different processor of the multiprocessor architecture. If the data is then requested from the processor, which originally had the data, then the data is acquired from a local memory of the particular processor that received and now has the data.

Claims (27)

1. A method implemented in a non-transitory machine-readable storage medium and processed by one or more processors configured to perform the method, comprising:

detecting, by a kernel process of an Operating System (OS), that a local memory for a first processor of a multiprocessor system has reached a threshold capacity level;

identifying, by the kernel processing, a second memory local to a second processor of the multiprocessor system with excess capacity by accessing a system metric table that includes a second processor identifier for the second processor, a second memory identifier for the second memory of the second processor, and a current usage value representing a current capacity of the second memory; and

offloading, by the kernel process, data from the local memory of the first processor to the second memory local to the second processor through inter-processor communications between the first processor and the second processor to increase capacity of the local memory and decrease capacity of the second memory based on the system metric table having the current usage value for the second memory, wherein the local memory and the second memory are volatile memories, wherein offloading the data further includes providing, by the first processor, the offloaded data from the local memory to the second processor for temporary storage in the second memory and instructing the second processor to write the offloaded data to non-volatile storage on behalf of the first processor when the second processor is experiencing less processing load relative to the first processor.

2. The method of claim 1 further comprising, receiving, by the kernel process, a request for the data on the first processor and obtaining the data from the second memory local to the second processor to satisfy the request.

3. The method of claim 1 further comprising, updating, by the kernel process, the system metric table local to include update capacity values for the local memory and the second memory once the data is offloaded from the local memory to the second memory.

4. The method of claim 1 , wherein detecting further includes acquiring the threshold capacity level as a processing parameter associated with the OS executing on the first processor.

5. The method of claim 1 , wherein detecting further includes obtaining the threshold capacity level as an environmental variable set with a percentage value for the OS executing on the first processor.

6. The method of claim 1 , wherein identifying the second memory further includes accessing the system metric table for the multiprocessor system having the current usage value for the second memory local to the second processor along with other current capacity values for other memories local to other processors of the multiprocessor system.

7. The method of claim 6 , wherein accessing further includes receiving periodic communications from the second processor and the other processors to update the system metric table.

8. The method of claim 7 further comprising, periodically broadcasting a present capacity value for the local memory of the first processor to the second processor and the other processors, the second processor and each of the other processors maintain an independent version of the system metric table in each of their local processing environments.

9. The method of claim 1 , wherein offloading the data further includes identifying the data as a particular cache or portion of cache that was to be discarded or offloaded to storage by the first processor to make room in the local memory for other data being handled by the first processor.

10. A method implemented in a non-transitory machine-readable storage medium and processed by one or more processors configured to perform the method, comprising:

detecting, by a kernel processing of an Operating System (OS), a condition indicating data in a local memory of a first processor is to be transitioned to one or more second memories local to one or more second processors in a multiprocessor system, wherein the local memory and the one or more second memories are volatile memories;

ensuring, by the kernel process, the some or all of the one or more second memories can handle excess capacity associated with receiving the data; and

transitioning, by the kernel process, the data to particular ones or all of the second memories based on current capacity levels for each of the second memories based a system metric table that includes second processor identifiers for the second processors, second memory identifiers for the second memories, and current usage values for each of the second memories and by identifying a threshold capacity level for the local memory and each of the second memories during a boot of the first processor and the one or more second processors, wherein transitioning further includes offloading some of the data in the local memory to the one or more second memories when the one or more second processors are experiencing less processing loads than the first processor based on the current usage values from the system metric table and through inter-processor communications between the first processor and the one or more second processors on the multicore processor system that is a multicore processor machine, and writing, by the one or more second processors, that data to non-volatile storage and removing, by the one or more second processors, that data from the one or more second memories once written to the non-volatile storage.

11. The method of claim 10 , wherein detecting further includes identifying the condition as an idle state for the first processor and the second processors and the data is transitioned to replicate one or more caches associated with the local memory to the second memories.

12. The method of claim 11 further comprising, transitioning an application using the data from the first processor to one of the second processors when the first processor reaches the threshold processing capacity level.

13. The method of claim 10 , wherein detecting further includes identifying the condition as a state associated with the local memory indicating the local memory is approaching a threshold capacity level and the data is being removed from the local memory to make room for other data.

14. The method of claim 10 , wherein ensuring further includes selecting a particular second memory for a particular second processor based on the condition.

15. The method of claim 10 , wherein ensuring further includes dynamically accessing the system metric table having the current usage values for each of the second memories to ensure the second memories can handle the excess capacity associated with receiving the data.

16. A multi-processor implemented system, comprising:

a multicore processor machine having multiple processors; and

the multicore processor machine configured with and to execute a memory manager on each of the processors;

each memory manager configured to execute as a kernel process within an Operating System (OS), and each memory manager configured to monitor capacity for local memory associated with each memory manager's processor through a system metric table that includes an identifier for each processor, an identifier for each local memory, and a current usage value for each local memory, wherein each memory manager is also configured to migrate data from its local memory to another processor's local memory based on policy evaluation in view of current usage values for the local memories and a threshold capacity level, wherein the local memories are volatile memories, and wherein at least one processor provides some data from that processor's local memory to a different processor when the different processor is experiencing less processing load than that at least one processor, and the different processor receives that data in the different processor's local memory, writes that data to non-volatile storage, and removes that data from the different processor's local memory through inter-processor communications between the at least one processor and the different processor on the multicore processor machine.

17. The system of claim 16 , wherein the each memory manager is to maintain a particular system metric table for updating the current usage values.

18. The system of claim 17 , wherein each memory manager is to broadcast an existing capacity level for its local memory to other instances of the memory managers so each of the other instances of the memory managers can update its system metric table current usage values with the existing capacity level for each of the processors.

Assignments (11)
RELEASE OF SECURITY INTEREST REEL/FRAME 035656/0251 Recorded Feb 2, 2023
From: JPMORGAN CHASE BANK, N.A.
To: BORLAND SOFTWARE CORPORATION; ATTACHMATE CORPORATION; NETIQ CORPORATION; MICRO FOCUS (US), INC.; MICRO FOCUS SOFTWARE INC. (F/K/A NOVELL, INC.)
Reel/Frame 062623/0009 →
RELEASE OF SECURITY INTEREST REEL/FRAME 044183/0718 Recorded Feb 2, 2023
From: JPMORGAN CHASE BANK, N.A.
To: MICRO FOCUS LLC (F/K/A ENTIT SOFTWARE LLC); BORLAND SOFTWARE CORPORATION; MICRO FOCUS (US), INC.; SERENA SOFTWARE, INC; ATTACHMATE CORPORATION; MICRO FOCUS SOFTWARE INC. (F/K/A NOVELL, INC.); NETIQ CORPORATION
Reel/Frame 062746/0399 →
RELEASE OF SECURITY INTEREST RECORDED AT REEL/FRAME - 042388/0386 AND REEL/FRAME - 044183/0577 Recorded Mar 18, 2019
From: JPMORGAN CHASE BANK, N.A.
To: SUSE LLC
Reel/Frame 048628/0221 →
RELEASE OF SECURITY INTEREST RECORDED AT REEL/FRAME - : 044183/0718 Recorded Mar 18, 2019
From: JPMORGAN CHASE BANK, N.A.
To: SUSE LLC
Reel/Frame 048628/0436 →
ASSIGNMENT OF ASSIGNOR'S INTEREST Recorded Feb 20, 2019
From: MICRO FOCUS SOFTWARE INC.
To: SUSE LLC
Reel/Frame 048379/0548 →
CORRECTIVE ASSIGNMENT TO CORRECT THE TO CORRECT TYPO IN APPLICATION NUMBER 10708121 WHICH SHOULD BE 10708021 PREVIOUSLY RECORDED ON REEL 042388 FRAME 0386. ASSIGNOR(S) HEREBY CONFIRMS THE NOTICE OF SUCCESSION OF AGENCY. Recorded Jul 26, 2018
From: BANK OF AMERICA, N.A., AS PRIOR AGENT
To: JPMORGAN CHASE BANK, N.A., AS SUCCESSOR AGENT
Reel/Frame 048793/0832 →
SECURITY INTEREST Recorded Oct 11, 2017
From: ENTIT SOFTWARE LLC; ATTACHMATE CORPORATION; BORLAND SOFTWARE CORPORATION; NETIQ CORPORATION; MICRO FOCUS (US), INC.; MICRO FOCUS SOFTWARE, INC.; ARCSIGHT, LLC; SERENA SOFTWARE, INC.
To: JPMORGAN CHASE BANK, N.A.
Reel/Frame 044183/0718 →
NOTICE OF SUCCESSION OF AGENCY Recorded May 2, 2017
From: BANK OF AMERICA, N.A., AS PRIOR AGENT
To: JPMORGAN CHASE BANK, N.A., AS SUCCESSOR AGENT
Reel/Frame 042388/0386 →
CHANGE OF NAME Recorded Sep 13, 2016
From: NOVELL, INC.
To: MICRO FOCUS SOFTWARE INC.
Reel/Frame 040020/0703 →
SECURITY INTEREST Recorded May 13, 2015
From: MICRO FOCUS (US), INC.; BORLAND SOFTWARE CORPORATION; ATTACHMATE CORPORATION; NETIQ CORPORATION; NOVELL, INC.
To: BANK OF AMERICA, N.A.
Reel/Frame 035656/0251 →
ASSIGNMENT OF ASSIGNOR'S INTEREST Recorded Feb 15, 2011
From: KARTHIKESAN, NIKANTH
To: NOVELL, INC.
Reel/Frame 025799/0385 →
Cited By (1)
US 12,659,369