Browse Prior Art Database

Method for dynamic quota thresholding for an event logging infrastructure Disclosure Number: IPCOM000247779D
Publication Date: 2016-Oct-06
Document File: 4 page(s) / 133K

Publishing Venue

The Prior Art Database


Method for dynamic quota thresholding for an event logging infrastructure.

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

Page 01 of 4

Method for dynamic quota thresholding for an event logging infrastructure

Disclosed is a method to dynamically threshold the logging quota limit on the fly, when there is a genuine need for excessive logging.

In a firmware sub system that interacts with hardware, an event logging firmware component tends to be utilised that provides services of event collection and logging, to all other firmware components within the system as depicted in Figure 1 below. This helps in firmware failure debug and root cause identification.

Figure 1: Overview of a customer system which has an event logger firmware component that is responsible for  event recording and logging and transfer of event logs to the management console.

This task of event logging is achieved by using a shared memory buffer pool that generally is common to all the firmware components in the system attempting to perform logging. This shared buffer pool has limits for different logging group which are normally set-up statically up-front and initialised when the system is powered on or during a reset of the system. The figure 2-a depicts the static limits set-up for each logging group. Each logging group could contain one or more firmware components which share the logging group and the quota assigned to that logging group.

Figure 2­a Depicting the static quota allocation for each logging group  amounting to a total of 150MB.


Page 02 of 4

Figure 2­b  Shared memory buffer pool being utilised by different logging  groups

During the up time of the system, these quota limits are hard limits which cannot be altered based on varying user load scenarios.

In Figure 2-b above, during the run time of the system the event logs are populated into the system on a first come first serve basis without consideration whether it belongs to a particular logging group or not. The only thing that needs to be ensured is that a particular logging group has not gone past its logging quota limit, before the event log entry is populated into the shared memory buffer pool.

Now consider the situation where the "Logging Group 1" as depicted in Figure 2-a above, consisting of components "Hardware Init" and "I/O Sub System", has already exhausted the quota of 30MB and after that, the "I/O Init" component needs to populate critical event logs into the shared memory buffer pool, but since the allocated quota is already exhausted, no further logging activity is permitted. This leads to loss of critical log entries in the field. The loss of such log entries would...