Showing posts with label schedulers. Show all posts
Showing posts with label schedulers. Show all posts

Wednesday, May 23, 2012

Queues in the News

You might not have noticed, but queues have been in the news a lot lately. Not from the standpoint of computer performance but people performance or more accurately, crowd control. Most recently, queues popped up in the context of long delays expected at Heathrow airport due to big crowd arrivals for the London Olympics.

In a queue, at least everyone is pointing in the same logical direction. Moreover, if you snake the queue, as they do at Disneyland, people always feel close to the destination and can see it getting even closer as customers ahead of them are processed. That helps to minimize their level of frustration: the control part. For some reason, the post office hasn't figured this out yet.

And, last but not least, queues and computer performance still remain an inevitable perennial. Most recently having to do with the Internet.

Thursday, September 24, 2009

New Performance Papers from VMware

Two new performance whitepapers from VMware:
  1. VMware vSphere 4: The CPU Scheduler in VMware ESX 4
  2. Understanding Memory Resource Management in VMware ESX Server:
Both apply controlled measurements ("Experimental Environment"), as described in my latest Linux Technical Review article.

Thursday, August 13, 2009

A Funny Thing Happened on the Way to the Priority Queue

Suppose two workloads $W_a$ and $W_b$ access a common resource, e.g., the CPU. They each have response times $R_a$ and $R_b$, respectively. The response time $R_a$ is longer than you would like. A common way to try and improve $R_a$ is to give $W_a$ a higher priority at the CPU. That's what the Unix nice command is all about. For example, if $W_a$ were a Unix process then: nice -15 Wa, would give a higher priority than the default already assigned by the Unix scheduler. But how much better will it's response time be? Nice can't tell you that.

Saturday, May 24, 2008

Instrumentierung – die Chance für Linux?

My latest article for the German publication Linux Technical Review appears in Volume 8 on "Performance und Tuning" and discusses a possible roadmap for future Linux instrumentation and performance management capabilities. The Abstract reads:
  • German: Linux könnte seine Position im Servermarkt ausbauen, wenn es dem Vorbild der Mainframes folgte und deren raffiniertes Performance-Management übernähme.
  • English: Linux could be in a position to expand its presence in the server market by looking to mainframe computer performance management as a role model and adapting its instrumentation accordingly.

Topics discussed include a comparison of time-share scheduling (TSS) with fair-share scheduling (FSS) and the Linux Completely fair scheduler (CFS), how to achieve a more uniform interface to performance and capacity planning measurements, and the kind of advanced system management capabilities available on IBM System Z for both their mainframes and clusters.

Saturday, February 16, 2008

Board from the Back of the Bus (maybe not)

When boarding a tour bus, the driver often tells you to occupy seats at the back of the bus first. This protocol is assumed to be more efficient than filling seats from the front because people block the aisle while stowing their carry-on baggage and thereby impede the flow. So, back-filling is more efficient than front-filling but is it optimal? The same procedure is used by airlines that implement boarding by groups A, B, C, etc. Group A is usually seated at the rear of the aircraft. There are some variants with aircraft boarding (e.g., window seats before aisle seats) that also help to distribute the passenger weight more evenly. The question remains, however, is it optimal?

An astrophysicist recently decided to look into this question more carefully using Monte Carlo simulations and found some surprising results. He unexpectedly discovered that the common rear boarding procedure is actually the second worst procedure, since it is only slightly more efficient than boarding front-to-back! So surprised was he, that at first, he thought there was a bug in his code. Then it became apparent that there was something more subtle going on. MC sims showed that an optimal boarding method was for passengers to board 10 at a time in every other row, since loading luggage requires about two aisles of space. In this way, passengers are either stowing luggage or sitting in their seats, rather than waiting in the aisle, as they do in the other two protocols. Depending on the size of the aircraft, this boarding procedure produces a speed up of 5 to 10 times over the worst case. Of course, disembarking is still LIFO. :-)

I wonder if this result could have applications in the context of computer or network performance analysis and capacity planning?

Wednesday, June 13, 2007

Linux CFS: Completely Fair or Completely Fogged?

A while ago, I saw what looked like an interesting blog entry announcing a new task scheduler for Linux called CFS: Completely Fair Scheduler. I wanted to compare CFS with Fair Share scheduling (FSS); something that took off in the 1990's for UNIX operating systems and something I've looked into from a performance perspective, especially because FSS provides the fundamenal resource allocation mechanism for most VMM hypervisors.