A Random Walk

There has been much chatter and complaining about the “PenTile” displays used by Motorola in their latest phones. I decided to break out the old microscope to see what the big deal was all about.

The photos above are of the digits of the time display in the notification area at the top. The photo on the left is the Droid 3 and the right is the Droid 1. The Droid 3 utilizes four squares of (cw from upper left) Red, Green, White, and Blue. The Droid 1 utilizes three vertical bars of (left to right) Red, Green, and Blue.

PenTile Reference: www.nouvoyance.com/technology.html

I just recently replaced my quad-core Phenom II x4 955 with a hexa-core Phenom II x6 1090T. The ‘T’ designation in the model number indicates that the processor supports AMD’s Turbo Core functionality which allows the processor to ‘overclock’ up to three cores under certain circumstances. The default maximum core clock is 3.2GHz, but when three or more cores are idle, Turbo Core can boost the remaining cores to 3.6GHz. Read more on Turbo Core here.

Linux kernel 2.6.33.3 and the 1090T do not play nice together. The powernow-k8 driver does not properly detect cpu speed p-states. A kernel patch has been committed to address this (see this). Linux Magazine has an article that describes the problem, and the upcoming patch, and recommends disabling Cool’n'Quiet until a patched kernel is released.

UPDATE: Kernel version 2.6.33.4, released Wed May 12 2010, resolves this issue.

Continue reading ‘Powernow-k8 AMD Turbo Core Bug’ »

Linux Magazine has a few interesting articles relating to filesystem journals, internal and external, and how metadata performance is affected.

• Size Can Matter: Improving Metadata Performance with Ext4 Journal Sizing – Part I
• Size Can Matter: Ramdisk Journal Metadata Performance – Part 2
• Size Can Matter: Would You Prefer the Hard Drive or the Ramdisk this Evening? Part 3
• Harping on Metadata Performance: New Benchmarks

Continue reading ‘Journals, Metadata, and Performance’ »

There is a post by Endre Stølsvik entitled Linux Java Thread Priorities workaround that is definitely worth a read.

A few years ago I attempted to make use of low priority background threads to use idle cores to offload work. I quickly found that setting java thread priorities has no effect when running on Linux. Being unaware of workarounds, I abandoned the idea.

My solution was to manage the priority of individual work units by feeding small(ish) operations into a queue and starting (n) worker threads to service the queue. This worked well for non-blocking work (nio) but failed miserably for work that required blocking i/o.  Ideally, it would be possible to have a very low priority thread that runs mostly during periods when  other threads are blocked on i/o. Endre Stølsvik’s workaround should almost certainly make this possible.

The Problem

RAID level 5 (and 4 and 6) suffers from poor write performance due to the need to recalculate parity. Writes smaller than (n-1) * chunk size will necessitate that the the remaining chunks be read in order to compute a new parity chunk. This read-modify-write requirement significantly reduces performance for all non large sequential writes. To add insult to injury, the additional seeks necessary to read the missing chunks adds further I/O load which will slow down random reads. During periods of high write load, concurrent reads will suffer.

Continue reading ‘Linux Raid5 + Journal on SSD = Speed — Part I’ »