fidzu : kernel

In just one week, the 2018 Linux Plumbers Conference will begin on November 13 with microconferences, a refereed track, Networking Summit track, Kernel Summit track, BoFs, and more. The conference is completely sold out at this point, sadly we cannot accommodate those on the waiting list. Below is some information for conference attendees.

We look forward to seeing all of the attendees in Vancouver next week …

Pick Up Your Badge Early:

Registration is located on the Junior Ballroom Foyer (North Tower Third Floor) of the Sheraton Wall Centre. Pre-registration will open Monday from 3:00pm to 5:00pm. General Registration will be open from 8:00am to 5:00pm Tuesday to Thursday.

View the Schedule:

Overview schedule
Detailed schedule

Please email contact@linuxplumbersconf.org if you'd like to request any changes.

Opening Reception:

Date: Tuesday, 13 November
Time: 6:30 - 9:30 pm
Location: Craft Beer Market, 85 W 1st Ave
Buses will depart from outside the North Tower from 6:30pm

Note: Craft Beer Market is at least 30 minutes walk from the hotel but is possible for the intrepid (and waterproof).

Closing Party at Blue Water Café:

Date: Thursday, 15 November
Time: 6:30 - 10:00 pm
Location: Blue Water Café: 1095 Hamilton St
Buses will depart from Outside the North Tower from 6:15pm

Note: The venue is 8 minutes walk from the Hotel for those who wish to brave the November weather

Lunch Details:

Lunch is on your own from 12:30 to 2:00 each day (though some microconferences may alter slightly). This year, we opted not to do lunch cards because of difficulties finding a Canadian card vendor and problems with currency conversion. The hotel does have an on-site restaurant in the North Tower, but it's too small for all our attendees. A map with nearby restaurants is available (and hard copies can be had at the registration desk). For the adventurous, Davie Street, as the centre of the Gay Pride neighbourhood, has a lot of interesting restaurants and bars (Google is pretty up to date) but beware, they're all rather small and some are cash only.

Venue Details:

Event Venue

1088 Burrard Street
Vancouver,
British Columbia
V6Z 2R9
Canada

Hotel, Parking & Transportation

Please refer to the Hotel Web page.

07 Nov 2018 5:20pm GMT

"Antifragile" was the last volume in Nassim Taleb's Incerto series, but it has lost that distinction with the publication of "Skin in the Game: Hidden Asymmetries in Daily Life". This book covers a great many topics, but I will focus on only a few that relate most closely to my area of expertise.

Chapter 2 is titled "The Most Intolerant Wins: The Dominance of a Stubborn Minority". Examples include kosher and halal food, the English language (I plead guilty!!!), and many others besides. In all cases, if the majority is not overly inconvenienced by the strongly expressed needs or desires of the minority, the minority's preferences will prevail. On the one hand, I have no problem eating either kosher or halal food, so would be part of the compliant majority in that case. On the other hand, although I know bits and pieces of several languages, the only one I am fluent in is English, and I have attended gatherings where the language was English solely for my benefit. But there are limits. For example, if I were to attend a gathering in certain parts of (say) rural India or China, English might not be within the realm of possibility.

But what does this have to do with parallel programming???

This same stubborn-minority dominance appears in software, including RCU. Very few machines have more than a few tens of CPUs, but RCU is designed to accommodate thousands. Very few systems run workloads featuring aggressive real-time requirements, but RCU is designed to support low latencies (and even more so the variant of RCU present in the -rt patchset). Very few systems allow physical removal of CPUs while the systems is running, but RCU is designed to support that as well. Of course, as with human stubborn minorities, there are limits. RCU handles systems with a few thousand CPUs, but probably would not do all that well on a system with a few million CPUs. RCU supports deep sub-millisecond real-time latencies, but not sub-microsecond latencies. RCU supports controlled removal and insertion of CPUs, but not surprise removal or insertion.

Chapter 6 is titled Intellectual Yet Idiot (with the entertaining subtext "Teach a professor how to deadlift"), and, as might be expected from the title, takes a fair number of respected intellectual to task, for but two examples, Cass Sunstein and Richard Thaler. I did find the style of this chapter a bit off-putting, but I happened to read Michael Lewis's "The Undoing Project" at about the same time. This informative and entertaining book covers the work of Daniel Kahneman and Amos Tversky (whose work helped to inform that of Sunstein and Thaler), but I found the loss-aversion experiments to be unsettling. After all, what does losing (say) $100 really mean? That I will be sad for a bit? That I won't be able to buy that new book I was looking forward to reading? That I don't get to eat dinner tonight? That I go hungry for a week? That I starve to death? I just might give a very different answer in these different scenarios, mightn't I?

This topic is also covered by Jared Diamond in his most excellent book entitled "The World Until Yesterday". In the "Scatter your land" section, Diamond discusses how traditional farmers plant multiple small and widely separated plots of land. This practice puzzled anthropologists for some time, as it does the opposite of optimize yields and minimize effort. Someone eventually figured out that because these traditional farmers had no way to preserve food and limited opportunities to trade it, there was no value in producing more food than they could consume. But there was value in avoiding a year in which there was no food, and farming different crops in widely separated locations greatly decreased the odds that all their crops in all their plots would fail, thus in turn minimizing the probability of starvation. In short, these farmers were not optimizing for maximum average production, but rather for maximum probability of survival.

And this tradeoff is central to most of Taleb's work to date, including "Skin in the Game".

But what does this have to do with parallel programming???

Quite a bit, as it turns out. In theory, RCU should just run its state machine and be happy. In practice, there are all kinds of things that can stall its state machine, ranging from indefinitely preempted readers to long-running kernel threads refusing to give up the CPU to who knows what all else. RCU therefore contains numerous forward-progress checks that reduce performance slightly but which also allow RCU to continue working when the going gets rough. This sort of thing is baked even more deeply into the physical engineering disciplines in the form of the fabled engineering factor of safety. For example, a bridge might be designed to handle three times the heaviest conceivable load, thus perhaps surviving a black-swan event such as a larger-than-expected earthquake or tidal wave.

Returning to Skin in the Game, Taleb makes much of the increased quality of decisions when the decider is directly affected by them, and rightly so. However, I became uneasy about cases where the decision and effect are widely separated in time. Taleb does touch obliquely on this topic in a section entitled "How to Put Skin in the Game of Suicide Bombers", but does not address this topic in more prosaic settings. One could take a survival-based approach, arguing that tomorrow matters not unless you survive today, but in the absence of a very big black swan, a large fraction of the people alive today will still be alive ten years from now.

But what does this have to do with parallel programming???

There is a rather interesting connection, especially when you consider that Linux-kernel RCU's useful lifespan probably exceeds my own. This is not a new thought, and is in fact why I have put so much energy into speaking and writing about RCU. I also try my best to make RCU able to stand up to whatever comes its way, with varying degrees of success over the years.

However, beyond a certain point, this practice is labeled "overengineering", which is looked down upon within the Linux kernel community. And with good reason: Many of the troubles one might foresee will never happen, and so the extra complexity added to deal with those troubles will provide nothing but headaches for no benefit. In short, my best strategy is to help make sure that there are bright, capable, and motivated people to look after RCU after I am gone. I therefore intend to continue writing and speaking about RCU. :-)

04 Nov 2018 3:54am GMT

Imagine, purely hypothetically, that you were a kernel hacker working for Red Hat and for whatever reason you wanted to find a new challenge at a company with a strong committment to open source. What are the possibilities?

To begin with, as the statistics from the Linux Foundation's 2016 report demonstrate, you have to be stark raving mad to leave Red Hat. If you do, Intel and AMD look interesting (hello, Alan Cox). IBM is not bad, although since yesterday, you don't need to quit Red Hat to work for IBM anymore. Even Google, famous for being a black hole that swallows good hackers who are never heard from again, manages to put up a decent showing, Fuchsia or no. Facebook looks unimpressive (no disrespect to DaveJ intended).

Now, the no-shows. Both of them hail from Seattle, WA: Microsoft and Amazon. Microsoft made an interesting effort to adopt Linux into its public cloud, but their strategy was to make Red Hat do all the work. Well, as expected. Amazon, though, is a problem. I managed to get into an argument with David "dwmw2" Woodhouse on Facebook about it, where I brought up a somewhat dated article at The Register. The central claim is, the lack of Amazon's contribution is the result of the policy rolled all the way from the top.

(...) as far as El Reg can tell, the internet titan has submitted patches and other improvements to very few projects. When it does contribute, it does so typically via a third party, usually an employee's personal account that is not explicitly linked to Amazon.

I don't know if this culture can be changed quickly, even if Bezos suddenly changes his mind.

30 Oct 2018 3:26am GMT