Browse Prior Art Database

Factoring contention in to the priority calculation by the kernel

IP.com Disclosure Number: IPCOM000012679D
Original Publication Date: 2003-May-20
Included in the Prior Art Database: 2003-May-20
Document File: 2 page(s) / 42K

Publishing Venue

IBM

Abstract

This article covers a priorty-based calculation method based on resource contention and utilization, which currently is not factored into current priority/scheduling policies. New parameters would be introduced to monitor contention and utilization for resources.

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

Page 1 of 2

Factoring contention in to the priority calculation by the kernel

Our proposal is to introduce into the kernel a new priority calculation method based on resource contention and utilization. Our customers would have the option of using a traditional priority based on CPU utilization, or use a priority based on resource contention and utilization, or a combination of the two.

By monitoring resource utilization we can determine the amount of contention for a resource, and either allocate an additional time slice, or increase a holders priority to help reduce the contention.

Currently the kernel does not factor contention into any of it's policies, and limits it's reporting to utilization only. We want to bring the concept of contention into the kernel and have it proactively monitor and put in place mechanisms to address it dynamically.

The critical factors we have determined which drives contention for resource which we are proposing is the amount of time that elapsed between a resource being freed and taken again, the average time that it is held for, and the number of threads blocked waiting for the resource.

We proposed that for specified logical and physical resources that we monitor within the kernel these parameters and increase a threads priority based on threshold values which can be set per resource or system wide.

The threshold values will be based on a contention value which is calculated algorithmically using the time a resource is free and the average time it is held for combined with the number of waiters. For example, on a one second average the free time of the resource will calculated and this value will be factored into the number of waiters (1/free * waiters) and compared to the cut off value. A busy value will be calculated based on the average hold time multiplied by the number of waiter expressed as a percentage of time over a second.

When the threshold value is reached (cutoff value > contention factor) the holders priority will be increased to a tunable value which can be set either system...