Browse Prior Art Database

QoS Mechanism for Retry Based Memory Controllers

IP.com Disclosure Number: IPCOM000244718D
Publication Date: 2016-Jan-06
Document File: 2 page(s) / 42K

Publishing Venue

The IP.com Prior Art Database

Abstract

Disclosed is a QoS mechansim as part of the memory controller architecture. In any system architecture CPU, GPU and some of other special devices shares the coherent memory. If the memory page request has been done by L2/L3 the request needs to be serviced as soon as possible to avoid starvation. Generally, CPU has got highest priority to get the memory request to be serviced, so that time GPU goes secondary or lower priority and most probably the device will be starving. In the disclosed method the first part is that the QoS fields to identify and describe the memory controller about the priority levels and at the same time come up with the unique implementation with the memory controller command queue by dropping the particular read command and informing the L2/L3. The second part where a special retry can be given and already allocated entry in command Queue can be squashed.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 52% of the total text.

Page 01 of 2

QoS Mechanism for Retry Based Memory Controllers

Background:

With the advent of big-data applications faster and larger main memory is a requirement. DRAM has been and will be for time to come the technology choice for main memory. Most of the current memory controllers are agnostic to the source of the memory requests. For virtualization scenarios where QoS plays a critical role it will be good if memory controllers also are QoS aware.

In general the memory controller has got multiple blocks including command queue, write re-order queue, read re-order queue etc,
The Reads/Writes come into the command Queue.

The Command Q sends the commands to a Read/Write Queue from where the actual DRAM commands are sequenced to the DRAM.

The Read/Write Queue can be scheduled out of order to DRAM.

In a Retry based system memory controller behavior:

-Retry if the Command Q is full
-Retry if the Comand Q is full for a type of request (Reads, Prefetch etc).

Problem Statement:

With cloud and virtualization, QoS at all levels becomes critical. Main memory is a an important for many of the cloud workloads.

Implementing some sort of QoS for retry based memory controller is important. Todays memory systems don't have a notion of identifying one request from another

Implementation details: a. QoS field in Requests to Memory Controller will have a 2 bit field QoS field in requests to memory controller, some of the bus protocol already has some notion of Q bits but its not used for specific purpose, also this QoS bit can be set based for a high priority LPAR and can be set by the Hypervisor or Virtualization management software and the bits for example 11: Highest priority 00: Lowest priority.

There are multiple QoS mechanism can be applied based on the QoS bits.

b. QoS mechanism 1 based on the QoS bits: Memory Utilizati...