Jump to content
Sign in to follow this  

Entrevista com Con Kolivas ; 24 Julho 2007

Recommended Posts


A não perder em: http://www.apcmag.com/6735/interview_con_kolivas

Con Kolivas

Con Kolivas is a prominent developer on the Linux kernel and strong proponent of Linux on the desktop. But recently, he left it all behind. Why?

In this interview with APCMag.com, Con gives insightful answers exploring the nature of the hardware and software market, the problems the Linux kernel must overcome for the desktop, and why despite all this he's now left it all behind.

Read on for an honest appraisal of Linux, and why it has some way to go yet.

You wouldn't know it from seeing him online, but by day Con Kolivas works an anaesthetist at a hospital in Melbourne. Linux kernel hacking is just one of his hobbies.

Despite this, Con is one of the most well known names in Linux kernel development -- and with good reason. His focus on improving the kernel for desktop performance has won him a legion of fans, and his patchsets for the Linux kernel (marked as -ck) have had a significant impact. So much so that some of his changes have been directly incorporated into the kernel, and some of ideas inspire changes still taking place.

Recently, however, Con announced he was leaving it all behind. Interested in hearing what prompted the move I contacted Con to talk about the reasons for his leaving, what it takes to be a kernel developer, the future as he sees it.

The response I got was more than I bargained for -- in the conversation that followed, Con explored not just why he left, but also the challenges the Linux kernel must overcome as he sees it, and the very nature of the hardware and software market that led to the computing environment we have today. Whether you're a Windows user or Linux user, he makes some excellent points.

Rather than break up the Con's responses, we're publishing it as it stands. So grab a coffee, make yourself comfortable, and read on.

Interview with Con Kolivas part 1: computing is boring

APC: How did you get started developing for the Linux kernel, did you enjoy it, and what's the passion that drives you?

Normally this would be a straight forward question to answer. However at this time, I've had the opportunity to reflect on what really got me into kernel development, and I'll be able to answer it more thoroughly. So if you give me the latitude to answer it I might end up answering all your potential questions as well. This is going to be my view on personal computing history.

The very first computer I owned was 24 years ago. I've been fortunate to have been involved in the personal computer scene since not long after it actually began. In the time since then, I've watched the whole development of the PC, first with excitement at not knowing what direction it would take, then with anticipation at knowing where it would head and waiting for the developments.

In the late 1980s it was a golden era for computing. There were so many different manufacturers entering the PC market that each offered new and exciting hardware designs, unique operating system features and enormous choice and competition. Sure, they all shared lots of software and hardware design ideas but for the most part they were developing in competition with each other. It is almost frightening to recall that at that time in Australia the leading personal computer in numbers owned and purchased was the Amiga for a period.

Anyone who lived the era of the first Amiga personal computers will recall how utterly unique an approach they had to computing, and what direction and advance they took the home computer to. Since then there have been many failed attempts at resuscitating that excitement. But this is not about the Amiga, because it ultimately ended up being a failure for other reasons. My point about the Amiga was that radical hardware designs drove development and achieved things that software evolution on existing designs would not take us to.

At that time the IBM personal computer and compatibles were still clunky, expensive, glorified word processing DOS machines. Owners of them always were putting in different graphics and sound cards yearly, upgrading their hardware to try and approach what was built into hardware like the Amiga and the Atari PCs.

Enter the dark era. The hardware driven computer developments failed due to poor marketing, development and a whole host of other problems. This is when the software became king, and instead of competing, all hardware was slowly being designed to yield to the software and operating system design.

We're all aware of what became the defacto operating system standard at the time. As a result there was no market whatsoever for hardware that didn't work within the framework of that operating system. As a defacto operating system did take over, all other operating system markets and competition failed one after the other and the hardware manufacturers found themselves marketing for an ever shrinking range of software rather than the other way around.

Hardware has since become subservient to the operating system. It started around 1994 and is just as true today 13 years later. Worse yet, all the hardware manufacturers slowly bought each other out, further shrinking the hardware choices. So now the hardware manufacturers just make faster and bigger versions of everything that has been done before. We're still plugging in faster CPUs, more RAM, bigger hard drives, faster graphics cards and sound cards just to service the operating system. Hardware driven innovation cannot be afforded by the market any more. There is no money in it. There will be no market for it. Computers are boring.

Enter Linux. We all know it started as a hobby. We all know it grew bigger than anyone ever imagined it. It would be fair to say that it is now one of the most important of the very few competing pieces of software/operating system that remains and drives development of the defacto standard -- Windows. However, I believe it never deserved to become this. Had the innovative hardware driven development and operating system competition continued, there is no way it would have attracted as much following, developers and time to evolve into what it has become. The hardware has barely changed in all that time. PCs are ludicrously powerful compared to what they were when Linux first booted in 1991, but that's an issue of increased speed, not increased functionality or innovation.

Inferior but dominant: familiar story? The technology inside the PC was inferior and poorly architected compared to other competing systems of the day, but Microsoft's clever business tactics ensured its success in the long term because it ran Windows.

So what about the PC? Well the PC was 'dying' according to all accounts 20 years ago. We all know now that is crap and for the foreseeable future at least, the one all encompassing, information processing, communication (and frustration creator) is here to stay. The internet certainly has cemented that position for the PC.

So Linux was created to service the home desktop personal computer, and the PC is here to stay. For those who were looking for some excitement and enjoyment in using their computer, the defacto operating system just doesn't cut it. We want to tinker, we want control, we want power over everything. Or alternatively we believe in some sort of freedom or some combination of the above. So we use Linux. That is certainly how I got involved in Linux; I wanted something to use on the home desktop PC.

However, the desktop PC is crap. It's rubbish. The experience is so bloated and slowed down in all the things that matter to us. We all own computers today that were considered supercomputers 10 years ago. 10 years ago we owned supercomputers of 20 years ago.. and so on. So why on earth is everything so slow? If they're exponentially faster why does it take longer than ever for our computers to start, for the applications to start and so on? Sure, when they get down to the pure number crunching they're amazing (just encode a video and be amazed). But in everything else they must be unbelievably slower than ever.

Computers of today may be 1,000 times faster than they were a decade ago, yet the things that matter are slower.

The standard argument people give me in response is 'but they do such more these days it isn't a fair comparison'. Well, they're 10 times slower despite being 1000 times faster, so they must be doing 10,000 times as many things. Clearly the 10,000 times more things they're doing are all in the wrong place.

APC: So, the performance problems of Linux on the desktop became a key motivator for you?

Yes. I started to tinker with improving Linux on the desktop. "Surely if I have complete control over all the software I'll be able to speed things up," I thought. There must be a way to tweak this, tune that, optimise this and get more speedups? Userspace improvements seemed so limited when I got started in Linux. It barely worked on the desktop half the time so trying to get speed out of it on top would mean that nothing worked. The UNIX legacy was evident. We were shaping an operating system never designed for the desktop and it was going to hurt... a lot.

Eventually the only places I noticed any improvements in speed were kernel developments. They were never huge, but caused slightly noticeable changes in things like snappiness, behaviour under CPU load and so on. The first patchset I released to the public contained none of my own code and was for kernel 2.4.18 which was about February 2002. I didn't even know what C code looked like back then, having never actually been formally taught any computer science.

So I stuck with that for a while until the 2.6 development process was under way (we were still in a 2.5 kernel at the time). I watched the development and to be honest... I was horrified. The names of all the kernel hackers I had come to respect and observe were all frantically working away on this new and improved kernel and pretty much everyone was working on all this enterprise crap that a desktop cares not about.

Even worse than that, while I obviously like to see Linux run on 1024 CPUs and 1000 hard drives, I loathe the fact that to implement that we have to kill performance on the desktop. What's that? Kill performance? Yes, that's what I mean.

If we numerically quantify it with all the known measurable quantities, performance is better than ever. Yet all it took was to start up an audio application and wonder why on earth if you breathed on it the audio would skip. Skip! Jigabazillion bagigamaherz of CPU and we couldn't play audio?

Or click on a window and drag it across the screen and it would spit and stutter in starts and bursts. Or write one large file to disk and find that the mouse cursor would move and everything else on the desktop would be dead without refreshing for a minute.

I felt like crying.

I even recall one bug report we tried to submit about this and one developer said he couldn't reproduce the problem on his quad-CPU 4GB RAM machine with 4 striped RAID array disks... think about the sort of hardware the average user would have had four years ago. Is it any wonder the desktop sucked so much?

The developers were all developing for something that wasn't the desktop. They had all been employed by big name manufacturers who couldn't care less about the desktop (and still don't) but want their last 1% on their database benchmark or throughput benchmark or whatever.

Linux had won. We were now the biggest competition in the server and database market out there and all the big names cared about Linux. Money was pouring into development from all these big names into developing Linux's performance in these areas.

The users had lost. The desktop PC, for which linux started out as being development for, had fallen by the wayside. Performance, as home desktop users understand performance, was gone. Worse yet, there was no way to quantify it, and the developers couldn't care if we couldn't prove it. The one place I found some performance was to be gained on the desktop (the kernel) was now doing the opposite.

Interview with Con Kolivas part 2: his effort to improve Linux performance on the desktop

APC: So what did you do next to try to convince the Linux kernel devs of the need for more focus on end-users?

I set out to invent some benchmark to try and quantify performance problems in Linux on the desktop PC. The first benchmark I created called 'Contest' (pun intended). It was horribly complicated to use and set up and the results were difficult to interpret but at least I tried. It did help. Some changes did come about as a result of these benchmarks, but mostly on the disk I/O front. So I was still left looking at this stuttering CPU scheduling performance.

I had some experience at merging patches from previous kernels and ironically most of them were code around the CPU scheduler. Although I'd never learnt how to program, looking at the code it eventually started making sense.

I was left pointing out to people what I thought the problem was from looking at that particular code. After ranting and raving and saying what I thought the problem was, I figured I'd just start tinkering myself and try and tune the thing myself.

After a few failed experiments I started writing some code which helped... a lot. As it turns out people did pay attention and eventually my code got incorporated. I was never very happy with how the CPU scheduler tackled interactivity but at least it was now usable on the desktop.

Not being happy with how the actual underlying mechanism worked I set out to redesign that myself from scratch, and the second generation of the -ck patchset was born. This time it was mostly my own code. So this is the story of how I started writing my own code for the linux kernel.

In brief, following this I found myself writing code which many many desktop users found helped, but I had no way to quantify these changes. There is always a placebo element which makes the end user experience difficult to clarify as to whether there is an improvement or not.

However I have tried very hard to make myself relatively resistant to this placebo effect myself from years of testing, and I guess the fact that my website has close to 1 million hits suggests there are people who agree it makes a difference. This inability to prove quantitatively the advantage that -ck offered, though, was basically what would eventually spell out the death of it.

APC: What code did get incorporated into the mainline kernel?

Looking back, while the patchset has been well known, little of the actual code itself ended up in the mainline kernel, even if it spurned interest and development from other people in that time. Most of what did end up going in were changes to the CPU scheduler to improve interactivity, fairness, SMP user fairness, making 'nice' behave itself, hyperthread fairness and so on. There were lots of other minor contributions in other areas, such as the virtual memory subsystem, software suspend, disk i/o scheduling and random bugfixes.

The emphasis of what I did get involved in is still the area that there are many -ck patches in the last release I ever made (2.6.22-ck1). The remaining patches reflect where I still believe massive problems exist for the desktop, and ironically, despite my efforts to the contrary, the same problems seem to get magnified with each passing year.

It seems that the emerging challenges for the linux kernel on the desktop never seem to get whole-heartedly tackled by any full time developer, and only get a sideways glance when the problems are so obvious that even those on the linux kernel mailing list are willing to complain about them.

APC: Was there a toll on you for this voluntary involvement?

Yes. There is no doubt that whenever I was heavily involved, I would stay awake at night thinking up code solutions, I would be sleep deprived, and it had the possibility to impact on my work and family life. I tried very hard to never compromise those two for the sake of kernel development, but perhaps on occasion I did push it to far. I make an issue of never regretting anything I have done so I'm still pleased with my involvement till now.

APC: What was the driving force that caused you to hangup your kernel coding keyboard and the -ck patchset?

That's one of those 'I wish I had a dime for ever time I was asked that' sort of questions.

As most people are well aware, my involvement in kernel development was motivated on three fronts, and it has zero to do with my full time career and life.

First, it was lots of fun. I've always been a computer geek and enjoyed spending hours in front of the computer doing... well whatever really. So spending it on something that had become a passion for me was an obvious source of great enjoyment for me.

Second, it was an intellectual challenge. There seemed to be things that I always wish were done in the Linux kernel, and there were issues people didn't really care to tackle and so on. Trying to confront them head-on I was doing something I really hadn't done before in terms of high level programming. I learnt a heck of a lot about operating system design and all other really basic computer science things that most CS students probably are bored with.

However it was all new to me. There is precious little (and some would argue zero) new research in operating system design. Looking at linux there is innovation in the approach to tackling things, but it's not like there's anything new about the problems being fixed. The same issues have always been there in hardware vs software designs, and all the research has been done. I've seen many people accuse me of claiming I invented fair scheduling. Let me set the record straight. I make no such ridiculous claim.

What I did was take what was known and try and apply it to the constraints of current hardware designs and the Linux kernel framework. While the 'global picture' of the problems and solutions have been well known for many years, actually narrowing down on where the acute differences in hardware vs software have evolved has not. Innovation only lies in the application of those ideas. Academic approaches to solutions tend not to be useful in the real world. On the flip side, pure hackery also tend to be long term disasters even if initially they're a quick fix. Finding the right balance between hackery and not ignoring the many years of academic research is what is needed.

APC: Did you get that balance right?

Heck no. But that's what I strived for. I think there are precious few developers who do. If there is one failing in the human driven decision making in choosing what code goes where it is that it is impossible to recognise that (again I'm not saying it was my code).

Third, it was an ego trip. If I improved something that I cared about, I found that usually lots of other people cared about it. The reason for that obviously is that I was actually an ordinary desktop PC user that pretended to be a kernel hacker. So whenever I made improvements that affected desktop users, lo and behold lots of people cared about them. I recall a kernel hacker that I respected very much joked about my 'fans' and asking how he could attract a crowd. He has contributed possibly 1000 times more lines of code to linux kernel than myself, yet I had a 'following'.

I only attracted a following because I hacked on things I cared about. And the users told me so. The one thing that drove my development over the many years were the 'thank you's that I got from the users of the -ck patchset.

So I still haven't answered your question about what made me stop kernel development have I? I guess explaining my motivations helps me explain why I stopped.

The user response was still there. If anything, the users got more vocal than ever as I was announcing quitting kernel development.

The intellectual challenge? Well that still existed of course.

The fun? Yes that's what was killed. It stopped being fun. In my now quite public email announcing that I was quitting I explained it briefly. The -ck patchset was for quite a while, a meaningless, out of mainline's spotlight playground for my experiments. As the scope of changes got larger, the improvements became more drastic and were more acutely noticeable. This led to more and more people asking me when the changes would me merged into mainline. As the number of requests grew, my resolve to not get mainline involved diminished. So I'd occasionally post patches as examples to the linux kernel mailing list. This generated more interest and requests to get mainline involved. So I tried.

You asked before what patches from -ck got into mainline and I listed a whole lot of random minor patches. The magnitude of the changes in the patches that did _not_ get involved stands out far more than those that did get in.

APC: was there something that was the 'final straw' for you?

My first major rejection was the original staircase CPU scheduler. It stood out as being far better in interactivity than the mainline CPU scheduler, but ultimately, just as the mainline CPU scheduler, it had corner cases that meant it was not perfect. While I was still developing it, the attention moved away from the CPU scheduler at that time. The reason given by Andrew Morton (the maintainer and second last gateway into the mainline kernel) at the time was that the kernel had more burning issues and bugs to address.

Of course it did. There were so many subsystems being repeatedly rewritten that there was never-ending breakage. And rewriting working subsystems and breaking them is far more important than something that might improve the desktop right? Oops, some of my bitterness crept in there. I'll try and keep emotion out and just tell the rest of the story as objectively as I can.

The main problem was that there simply was not a convincing way to prove that staircase was better on the desktop. User reports were not enough. There was no benchmark. There was no way to prove it was better, and the user reports if anything just angered the kernel maintainers further for their lack of objectivity. I even tried writing a benchmark called Interbench. Note that interactivity is not responsiveness (I have a little summary of the difference as I see it with the Interbench code). This was much better code than Contest but even though I could demonstrate advantage with my scheduler on Interbench, the magnitude of the differences was difficult if not impossible to elicit based on the raw numbers generated by Interbench.

With a truckload of help from William Lee Irwin III (who wrote the main architecture) I posted a pluggable CPU scheduler framework that would allow you to build into the kernel as many of multiple CPU schedulers as you like and choose at boot time which one to run. I planned to extend that to runtime selection as well. This is much like the modular pluggable I/O scheduler framework that Linux kernel currently has. It was flat out refused by both Linus and Ingo (who is the CPU scheduler maintainer) as leading to specialisation of CPU schedulers and they both preferred there to be one CPU scheduler that was good at everything. I guess you can say the CPU scheduler is a steamroller that we as desktop users use to crack nuts with, and they didn't want us to build a nutcracker into the kernel.

The purpose of Plugsched was simply to provide a seamless way for the staircase CPU scheduler to be integrated into the mainline kernel. I didn't feel strongly about the presence of pluggable CPU schedulers, but many people still do and the code is still maintained today mainly by Peter Williams.

Then along came swap prefetch. I spent a long time maintaining and improving it. It was merged into the -mm kernel 18 months ago and I've been supporting it since. Andrew to this day remains unconvinced it helps and that it 'might' have negative consequences elsewhere. No bug report or performance complaint has been forthcoming in the last 9 months. I even wrote a benchmark that showed how it worked, which managed to quantify it! In a hilarious turnaround Linus asked me offlist 'yeah but does it really help'. Well, user reports and benchmarks weren't enough... It's still in limbo now but they'll have no choice but to drop it without anyone maintaining it.

Finally the nail in the coffin. The Staircase Deadline CPU scheduler. Initially started as a side project from the Staircase CPU scheduler I soon realised that it was possible to have excellent interactivity while fixing the horrible fairness issues that an unfair design had. Furthermore, it actually improved interactivity issues elsewhere that ended up being fairness problems, and fairness is of course paramount to servers and multiuser environments.

A lot of users and even kernel developers found that many long lasting complaints with the mainline and other schedulers were fixed by this code and practically begged me to push it into mainline, and one user

demanded Linus merge it as soon as possible as a bugfix. So I supported the code and fixed it as problems arose and did many bugfixes and improvements along the way.

Then I hit an impasse. One very vocal user found that the unfair behaviour in the mainline scheduler was something he came to expect. A flamewar of sorts erupted at the time, because to fix 100% of the problems with the CPU scheduler we had to sacrifice interactivity on some workloads. It wasn't a dramatic loss of interactivity, but it was definitely there. Rather than use 'nice' to proportion CPU according to where the user told the operating system it should be, the user believed it was the kernel's responsibility to guess. As it turns out, it is the fact that guessing means that no matter how hard and how smart you make the CPU scheduler, it will get it wrong some of the time. The more it tries to guess, the worse will be the corner cases of misbehaving.

The option is to throttle the guessing, or not guess at all. The former option means you have a CPU scheduler which is difficult to model, and the behaviour is right 95% of the time and ebbs and flows in its metering out of CPU and latency. The latter option means there is no guessing and the behaviour is correct 100% of the time... it only gives what you tell it to give. It seemed so absurdly clear to me, given that interactivity mostly was better anyway with the fair approach, yet the maintainers demanded I address this as a problem with the new design. I refused. I insisted that we had to compromise a small amount to gain a heck of a great deal more. A scheduler that was deterministic and predictable and still interactive is a much better option long term than the hack after hack approach we were maintaining.

Then I became very unwell. A disc prolapse in my neck basically meant I need to lie flat on my back for about 6 weeks. Yes, kernel development did contribute to this problem. So I was drugged to the eyeballs and spent most of the day and night lying down... having nothing to think about but stew over the kernel. Whenever I could I snuck back on the PC to try and support the code I had thrown out there. I refused to budge on the fairness aspect, and I kept getting that thrown back in my face as an unfixable failure in the design.

Then one day presumably Ingo decided it was a good idea and the way forward and... wrote his own fair scheduling interactive design with a modular almost pluggable CPU scheduling framework... and had help with the code from the person who refused to accept fair behaviour in my flamewar.

So I had plenty of time lying on my back to reflect on what I was doing and why, and whether I was going to regret it from that point on. I decided to complete the work on Staircase Deadline to make sure it was the reference for comparison, instead of having the CPU scheduler maintainer's new code comparing to the old clunky scheduler. Then I quit forever.

Are developer egos a problem in the open source development model in general?

I think any problem with any development model has multiple factors, and ultimately, it is humans that make decisions. I won't comment on the humans themselves.

If there is any one big problem with kernel development and Linux it is the complete disconnection of the development process from normal users. You know, the ones who constitute 99.9% of the Linux user base.

The Linux kernel mailing list is the way to communicate with the kernel developers. To put it mildly, the Linux kernel mailing list (lkml) is about as scary a communication forum as they come. Most people are absolutely terrified of mailing the list lest they get flamed for their inexperience, an inappropriate bug report, being stupid or whatever. And for the most part they're absolutely right. There is no friendly way to communicate normal users' issues that are kernel related. Yes of course the kernel developers are fun loving, happy-go-lucky friendly people. Just look at any interview with Linus and see how he views himself.

I think the kernel developers at large haven't got the faintest idea just how big the problems in userspace are. It is a very small brave minority that are happy to post to lkml, and I keep getting users telling me on IRC, in person, and via my own mailing list, what their problems are. And they've even become fearful of me, even though I've never viewed myself as a real kernel developer.

Just trawl the normal support forums (which I did for Gentoo users as a way of finding bug reports often because the users were afraid to tell me) and see how many obvious kernel related issues there are. I'd love to tell them all to suddenly flood lkml with their reports of failed boots with various kernels, hardware disappearing, stopping working suddenly, memory disappearing, trying to use software suspend and having your balls blown off by your laptop, and so on.

And there are all the obvious bug reports. They're afraid to mention these. How scary do you think it is to say 'my Firefox tabs open slowly since the last CPU scheduler upgrade'? To top it all off, the enterprise users are the opposite. Just watch each kernel release and see how quickly some $bullshit_benchmark degraded by .1% with patch $Y gets reported. See also how quickly it gets attended to.

What are you doing in your spare time now, and what future projects do you have planned?

I had some small userspace toys that I was experimenting with (compression tools, video encoding/conversion tools and a few others) that I thought I'd get back to. However just looking at any code gives me a bad taste in the mouth so that's not happening.

My current passion is learning Japanese. It's fun, it's a huge intellectual challenge, will allow me to eventually understand lots of interesting Japanese media in its native language (short stories, movies, manga and anime) and comes with no strings attached. I never really know what hobby I'll end up taking up but I usually get completely engrossed in whatever it was.

Thank you for your time Con.

Share this post

Link to post
Share on other sites

Não há mais? :)

Já conhecia algumas das razões para o Con Kolivas ter saído do desenvolvimento do kernel, mas agora fiquei mesmo esclarecido.

<3 life

Share this post

Link to post
Share on other sites

Entrevista traduzida para Português do Brasil:

in http://raelcunha.com/packages/blog/pages/index.tpl.php?post=205

Con Kolivas, um dos desenvolvedores mais ativos do kernel Linux, deixou o desenvolvimento do mesmo alguns dias atrás. O mesmo deu uma entrevista na APC Magazine, respondendo há várias perguntas, como o motivo de seu afastamento. Kolivas era um dos mais preocupados pelo desenvolvimento do Linux no desktop.

A tradução da entrevista foi feita pelo Thiago A. Silva, que gentilmente me enviou para publicá-la. Se alguém achar algum erro, ficaríamos feliz em que o mesmo seja reportado.

Todo o texto abaixo é parte da entrevista. Have fun!


Con Kolivas é um prominente desenvolvedor do kernel Linux e forte proponente desse sistema operacional no desktop. Mas recentemente ele deixou tudo para trás. Por quê

Nessa entrevista para a APCMag.com, Con dá respostas criteriosas explorando a natureza do mercado de hardware e software, os problemas que o kernel do Linux deve superar para o desktop, e por quê apesar disso tudo ele agora está deixando tudo para trás.

Leia a seguir uma honesta avaliação do Linux, e por quê este ainda tem um longo caminho para percorrer.

Você não saberia disso vendo-o online, mas Con Kolivas trabalha diariamente como anestesista num hospital de Melbourne. O hacking do kernel Linux é so um de seus hobbies.

Apesar disso, Con é um dos mais bem conhecidos nomes no desenvolvimento do kernel Linux – e com boa razão. Seu foco em melhorar o kernel para a performance do desktop o fez ganhar uma legião de fãs, e seus patchsets para o kernel do Linux (marcados como -ck) têm tido significante impacto. Tanto que algumas de suas mudanças foram diretamente incorporadas ao kernel, e algumas de suas idéias inspiram mudanças que ainda estão ocorrendo.

Recentemente, no entanto, Con anunciou que estava deixando tudo para trás. Interessado em escutar o que o levou à mudança eu contatei Con para falar sobre as razões de sua saída, o que é preciso para ser um desenvolvedor do kernel, e o futuro como ele o enxerga.

A resposta que eu tive foi mais do que eu pechinchei – na conversação que se seguiu, Con explorou não somente porque ele deixou, mas também as mudanças que o kernel do Linux tem que enfrentar como ele as enxerga, e a exata natureza do mercado de hardware e software que levaram ao ambiente de computação que temos hoje. Se você é um usuário de Linux ou até de Windows, ele dá excelentes apontamentos.

Ao invés de quebrar as respostas de Con, estamos publicando-as como foram ditas. Então pegue um café, relaxe e leia a seguir.

APC: Como você começou a desenvolver para o Kernel do Linux, você gostou, e qual a paixão que te motiva?

Normalmente essa seria uma questão direta para responder. Porém no momento, eu tive a oportunidade de refletir sobre o que realmente me fez participar do desenvolvimento do Kernel, e eu poderei responder a pergunta de forma mais ponderada. Então se você me der a latitude eu provavelmente acabarei respondendo todas as suas questões potenciais também. Essa será minha visão na história da computação pessoal.

Eu tive meu primeiríssimo computador há 24 anos atrás. Fui sortudo de ter me envolvido na cena da computação pessoal não muito depois que ela começou. Desde então eu assisti todo o desenvolvimento do PC, primeiramente com a excitação de não saber qual direção tomaria, e depois com antecipação, sabendo onde se dirigiria e esperando pelo desenvolvimento.

O final dos anos 80 foi uma era de ouro para a computação. Existiam muitos fabricantes diferentes entrando no mercado dos PCs e cada um deles oferecia novos e excitantes designs de hardware, funções únicas de sistemas operacionais e um enorme poder de escolha e competição. Claro, todos eles compartilhavam muitas idéias de design de hardware e software, mas na maior parte do tempo estavam desenvolvendo uma competição uns com os outros. É quase assustador relembrar que naquele tempo, na Austrália, o computador pessoal dominante em números de propriedade e compra foi o Amiga, por um período.

Qualquer pessoa que viveu a era do primeiro computador pessoal Amiga vai relembrar o quão único era seu método de computação, e para qual direção e avanço ele levou o computador caseiro. Desde então existiram muitas tentativas frustradas de ressucitar aquela excitação. Mas isso não é sobre o Amiga, porque no final das contas ele acabou sendo um fracasso por outras razões. Minha observação sobre o Amiga é que designs de hardware radicais dirigiam o desenvolvimento e conquistavam coisas que a evolução do software nos designs existentes nunca nos levariam.

Naquele tempo os computadores pessoais da IBM e compatíveis ainda eram pesados, caros, admiradas máquinas de processamento de texto DOS. Os possuidores dessas máquinas sempre colocavam, todo ano, placas de som e de vídeo diferentes, fazendo o upgrade do hardware para tentar se aproximar do que era constituído dentro de computadores Amiga e PCs Atari.

Então entra a era obscura. O desenvolvimento de computadores liderados por hardware falharam por causa do fraco marketing e desenvolvimento, além de vários outros problemas. Foi quando o software se tornou rei, e em vez de competir, todo o hardware foi vagarosamente sendo moldado de modo a dar lucro para o design de software e sistemas operacionais.

Todos nós sabemos em que se tornou o de fato sistema operacional padrão naquele tempo. Como resultado não existia mercado, seja qual for, para o hardware que não funcionava com o framework daquele sistema operacional. Enquanto um SO tomou tudo, todos os mercados de SOs e a competição falharam um atrás do outro e os fabricantes de hardware encontraram-se vendendo para um círculo gradualmente menor de software, ao invés do caminho inverso.

O hardware desde então tornou-se subserviente do sistema operacional. Isso começou mais ou menos em 1994 e ainda é verdadeiro hoje em dia, 13 anos depois. Pior ainda, todos os fabricantes de hardware foram aos poucos comprando uns aos outros, diminuindo adiante as escolhas de hardware. Então agora os fabricantes de hardware fazem versões mais rápidas ou maiores de tudo o que já foi feito antes. Nós ainda estamos plugando CPUs mais rápidas, mais RAM, HDs maiores, placas de vídeo mais rápidas e placas de som para servir ao sistema operacional. Inovação dirigida por hardware não pode mais ser assimilada pelo mercado. Não existe dinheiro nele. Não haverá mercado para isso. Computadores são chatos.

Então vem o Linux. Todos sabemos que começou como um hobby. Todos sabemos que ficou maior do que qualquer um já imaginou. Seria justo dizer que é hoje uma das mais importantes peças competidoras de software/sistemas operacionais que resta e dirige o desenvolvimento do padrão de fato – Windows. No entanto, eu acredito que ele nunca mereceu ter se tornado nisso. Se o inovador desenvolvimento dirigido por hardware e a competição de sistemas operacionais tivesse continuado, de nenhuma forma o Linux teria atraído tantos desenvolvedores fiéis e tempo para tornar-se no que é hoje. O hardware pouco mudou em todo esse tempo, PCs são absurdamente mais poderosos se comparados com o que eles eram quando o Linux deu seu primeiro boot em 1991, mas só por causa da maior velocidade do hardware, não de maior funcionalidade ou inovação.

Então que tal o PC? Bem, o PC estava 'morrendo' de acordo com todos os indícios há 20 anos atrás. Todos sabemos agora que isso é besteira e pelo futuro previsto pelo menos, esse todo envolvedor, o processamento de informações, comunicação (e criadora de frustrações) está aqui para ficar. A internet certamente fortaleceu a posição do PC.

Então o Linux foi criado para servir à computaçãp pessoal dos desktops, e o PC está aqui para ficar. Para aqueles que estavam procurando por alguma excitação e diversão usando seus computadores, o de fato sistema operacional não te entrega isso. Nós queremos consertar, nós queremos controle, queremos poder sobre tudo. Ou alternativamente nós acreditamos em alguma espécie de liberdade ou uma combinação dos anteriores. Então nós usamos Linux. Essa foi certamente a forma que eu me envolvi com o Linux. Eu queria algo para usar no meu computador desktop de casa.

De qualquer forma, o PC desktop é sujo. É cheio de entulhos. A experiência é bastante vagarosa em todas as coisas que importam. Todos nós possuímos computadores hoje que eram considerados supercomputadores 10 anos atrás. Há 10 anos atrás nós possuíamos supercomputadores de 20 anos atrás... e assim vai. Então por que diabos tudo é tão lento? Se eles são exponencialmente mais rápidos por que demora mais que nunca para nossos computadores iniciarem, para as aplicações iniciarem e tudo o mais? Claro, quando se rendem aos números puros e esmagadores eles são fantásticos (faça o encode de um vídeo e fique maravilhado). Mas no resto das coisas eles têm que ser inacreditavelmente mais vagorosos.

Computadores de hoje devem ser 1.000 vezes mais rápidos do que eram há uma década atrás, e ainda assim as coisas que importam são mais lentas.

O argumento padrão que as pessoas me dão em resposta é "mas eles fazem tão mais nesses dias que não é uma comparação justa". Bem, eles são 10 vezes mais lentos apesar de serem 1.000 vezes mais rápidos, então devem estar fazendo 10.000 vezes mais coisas. Claramente as 10.000 vezes mais coisas que fazem estão no lugar errado.

APC: Então, os problemas de performance do Linux no desktop tornaram-se uma motivação para você?

Sim. Eu comecei a pensar em melhoramentos no desktop Linux. "Certamente se eu tiver controle completo sobre todo o software, poderei acelerar as coisas," eu pensei. Tem que existir uma forma de ajustar isso, afinar aquilo, otimizar isso e conseguir mais melhorias na velocidade? Melhoras no Userspace pareciam bastante limitadas quando eu comecei no Linux. Na metade do tempo funcionavam pouco no Desktop, então tentar conseguir velocidade disso na verdade significaria que nada funcionava. O legado do UNIX era evidente. Nós estávamos moldando um sistema operacional que nunca foi feito para o Desktop e isso ia doer... um bocado.

Eventualmente os únicos cantos que notei melhoras na velocidade foram desenvolvimentos no Kernel. Nunca eram imensos, mas causaram parcamente mudanças notáveis em coisas como ligeireza, comportamento sobre CPU carregada e assim vai. O primeiro patchset que eu liberei para o público não continha nenhum código meu e foi para o kernel 2.4.18, mais ou menos em fevereiro de 2002. Eu não sabia como era o código C antes disso, nunca me tendo sido ensinada nenhuma ciência de computação.

Então eu me emperrei com aquilo por um tempo, até que o processo de desenvolvimento do kernel 2.6 estava a caminho (nós ainda estávamos no kernel 2.5 naquele tempo). Eu assisti o desenvolvimento e para ser honesto... fiquei chocado. Os nomes de todos os hackers do kernel que eu vim a respeitar e observar estavam freneticamente deslizando nesse novo e melhorado kernel e quase todo mundo estava trabalhando nesse lixo empresarial que um desktop não precisa.

Ainda pior que isso, enquanto eu obviamente gosto de ver o Linux rodar em 1.024 CPUs e 1.000 hard drives, eu detesto o fato que para implementar isso nós temos que matar performance no desktop. O que é isso? Matar performance? Sim, é isso que quero dizer.

Se numericamente quantificarmos isso com todas as quantidades mesuráveis, a performance é melhor do que nunca. Ainda assim tudo o que isso levou foi iniciar uma aplicação de áudio e admirar-se por que diabos se você respirasse nela o áudio iria saltar. Saltar! Jigabazillion bagigamaherz da CPU e nós não poderíamos tocar áudio?

Ou clicar em uma janela e deslizá-la através da tela e a mesma começaria a cuspir e gaguejar em arranques. Ou escrever um arquivo grande no disco e ver que o o cursor do mouse moveria, mas todo o restante no Desktop estaria morto e sem atualização por um minuto.

Eu senti como se estivesse chorando.

Até lembro um bug report que tentamos enviar sobre isso e um desenvolvedor disse que não poderia reproduzir o problema em sua máquina QUAD-CPU 4GB RAM com 4 discos striped RAID array... pense sobre o tipo de hardware que o usuário comum teria há quatro anos atrás. É de se maravilhar que o Desktop era um lixo?

Os desenvolvedores estavam todos desenvolvendo para algo que não era o Desktop. Todos foram empregados por grandes fabricantes que não se importavam com o Desktop (e ainda não se importam), mas os desenvolvedores querem seus últimos 1% nos benchmarks de banco de dados deles ou seja lá o que for.

O Linux ganhou. Nós éramos os maiores competidores nos mercados de servidores e banco de dados afora e todos os grandes nomes se importavam com o Linux. O dinheiro de todos esses grandes nomes estava chovendo para melhorar a performance do Linux nessas áreas.

Os usuários perderam. O PC Desktop, para qual o Linux começou a se desenvolver, caiu para as marginais. A performance, como os usuários de desktop entendem performance, se foi. Pior ainda, não havia modo de quantificar isso, e os desenvolvedores não ligariam se nós não pudéssemos provar isso. O único lugar que vi que alguma performance deveria ser ganha no desktop (o kernel) estava agora fazendo o oposto.

APC: Então o que você fez para tentar convencer os desenvolvedores do kernel da necessidade de focar os usuários finais?

Eu criei alguns benchmarks para tentar quantificar os problemas de performance do Linux no desktop. O primeiro benchmark que criei chamava-se 'Contest' (a intenção era fazer um trocadilho). Era terrivelmente complicado de usar e configurar e os resultados eram difíceis de interpretar, mas pelo menos eu tentei. E ajudou. Algumas mudanças vieram como resultado desses benchmarks, principalmente na disk I/O front. Então ainda fiquei contemplando a performance gaguejante da CPU shedulling.

Eu tive alguma experiência em fundir patches de kernels anteriores e ironicamente a maior parte deles tinham códigos ao redor da CPU scheduler. Apesar de eu nunca ter aprendido a programar, olhando para o código o mesmo eventualmente começou a fazer sentido.

Então comecei a apontar para as pessoas o que eu pensei que o problema era, olhando para aquele código particular. Depois de gritar e dizer o que eu pensava que o problema era, compreendi que poderia começar a consertar e otimizar o negócio eu mesmo.

Depois de alguns experimentos frustrados comecei a escrever algum código que ajudou... um bocado. As pessoas começaram a prestar atenção e eventualmente meu código foi incorporado. Eu nunca estava muito feliz com a forma que a CPU scheduler cuidava da interatividade, mas pelo menos agora estava usável no desktop.

Não estando feliz com a forma como o mecanismo de base trabalhava, comecei a refazer o design eu mesmo do zero, e a segunda geração do patchset -ck nasceu. Dessa vez a maior parte do código era minha. Então essa é a história de como comecei a escrever meu próprio código para o kernel do Linux.

Resumidamente, seguindo isso encontrei-me escrevendo códigos que muitos, muitos usuários de desktop acharam úteis, mas eu não tinha formas de quantificar essas mudanças. Sempre tem um elemento "Placebo" que faz a experiência do usuário final difícil de esclarecer, ou se existe um melhoramento ou não.

No entanto tentei arduamente tornar-me resistente a esse efeito "Placebo" durante anos de teste, e concluí pelo fato de meu website ter 1 milhão de sugestões que existem pessoas que concordam que de fato faz alguma diferença. Essa inabilidade de provar quantitativamente a vantagem que o -ck oferece, apesar disso, foi o que eventualmente prenunciou sua morte.

APC: Qual código foi incorporado ao kernel mainline?

Olhando para trás, enquanto o patchset foi bem conhecido, pouco do código atual acabou entrando no kernel mainline, mesmo tendo desdenhado interesse e desenvolvimento de outras pessoas naquele tempo. A maior parte que foi incluída foram mudanças na CPU scheduler para melhorar a distribuição (fairness), distribuição do user SMP, fazendo-o comportar-se bem por si mesmo, distribuição da hyperthread, e por aí vai. Existiram várias outras contribuições menores em outras áreas, como o subsistema de memória virtual, software suspend, disk I/O scheduling e bugfixes aleatórios.

A ênfase do que eu me envolvi ainda é na área que tem vários patches -ck do último release que liberei (2.6.22-ck1). Os patches restantes refletem onde eu ainda acredito que problemas massivos existam no desktop, e ironicamente, apesar de meus esforços para o contrário, os mesmos problemas parecem ser magnificados a cada ano que passa.

Parece que os desafios emergentes para o kernel do Linux no desktop nunca são enfrentados totalmente de coração por nenhum desenvolvedor de tempo integral, e apenas obtém um relance sem importância quando os problemas são tão óbvios que até mesmo aqueles na mailing list do kernel estão desejosos de reclamar sobre eles.

APC: Existiu um "pedágio" em você por esse envolvimento voluntário?

Sim. Sem dúvidas, não importando o quão pesadamente eu estivesse envolvido, eu ficaria acordado durante a noite pensando em soluções de código, eu teria o sono negado, e isso poderia ter impacto no meu trabalho e vida familiar. Eu tentei arduamente nunca comprometer essas duas coisas pela causa do desenvolvimento do kernel, mas talvez na ocasião eu tenha empurrado isso muito para frente. Eu faço um esforço para nunca me lamentar de nada que fiz, então ainda estou satisfeito com meu envolvimento até agora.

APC: Qual foi a força motriz que fez você se desligar do desenvolvimento e do patchset -ck?

Essa é uma daquelas "Eu desejaria ter uma moeda de 10 cents para toda vez que me perguntarem esse tipo de coisa".

Como a maioria das pessoas estão cientes, meu envolvimento no kernel foi motivado em três frontes, e não tem nada a ver com minha carreira nem com minha vida.

Primeiro, foi bastante divertido. Eu sempre fui um geek e gosto de passar horas em frente ao computador fazendo... bem, qualquer coisa, realmente. Então gastar tempo em algo que se tornou uma paixão para mim foi uma óbvia fonte de grande diversão.

Segundo, foi um desafio intelectual. Pareciam haver coisas que eu sempre desejei ver no kernel do Linux, e existiam assuntos que as pessoas realmente não se importavam em tentar resolver, e por aí vai. Na tentativa de confrontar eles diretamente eu estava fazendo algo que realmente não havia feito antes em termos de programação de alto nível. Eu aprendi um monte de coisas sobre design de sistemas operacionais e todas as outras coisas básicas de ciências da computação com as quais a maioria dos estudantes provavelmente estão chateados.

No entanto, tudo era novo para mim. Existem poucas (e alguns diriam zero) pesquisas novas em design de sistemas operacionais. Olhando para o Linux existe inovação na forma de tocar as coisas adiante, mas não que exista nada novo sobre os problemas que estão sendo consertados. Os mesmos assuntos sempre estiveram aí em design de hardware vs software, e toda a pesquisa foi feita. Eu vi várias pessoas me acusarem de alegar ter inventado o fair scheduling. Deixe-me clarear as coisas, eu nunca fiz uma alegação tão ridícula.

O que eu fiz foi pegar o que era conhecido e tentar aplicar para as constantes atuais do design de hardware e o framework do kernel do Linux. Enquanto a 'figura global' dos problemas e soluções já era conhecida há anos, o estreitamento do ponto onde as diferenças agudas de hardware vs software se desenvolveram não o é. A inovação está apenas na aplicação dessas idéias. Métodos acadêmicos para soluções tendem a não ser úteis no mundo real. No lado oposto, o método hacker também tende a ter desastres a longo prazo até mesmo se inicialmente mostrarem ser uma solução. Encontrar o balanço ideal entre o método hacker e não ignorar os vários anos de pesquisas acadêmicas é o que é necessário.

APC: Você assimilou o balanço corretamente?

Não. Mas me esforcei para isso. Eu acho que são poucos os desenvolvedores que conseguem. Se existe uma falha na decisão por humanos em escolher qual código vai onde vai, é impossível reconhecer aquilo (outra vez estou dizendo que não é meu código).

Terceiro, foi uma viagem de ego. Se eu melhorasse algo que me importasse, veria que muitas outras pessoas se importariam também. A razão para isso, obviamente, é que eu era de fato um usuário ordinário de PC que fingiu ser um hacker do kernel. Então sempre que eu fazia melhorias que afetavam os usuários de desktop, muitas pessoas se importavam com elas. Eu lembro que um hacker do kernel que eu respeitava bastante fez uma piada sobre meus "fãs" e perguntou como ele poderia atrair uma multidão. Ele contribuiu possivelmente com 1000 vezes mais linhas de código para o kernel do Linux que eu, e ainda assim eu tinha "seguidores".

Eu apenas atraí isso porque hackeei coisas com as quais me importava. E os usuários confirmaram isso. As únicas coisas que me fizeram continuar o desenvolvimento ao longo de vários anos foram os agradecimentos que recebi dos usuários do patchset -ck.

Então, eu ainda não respondi sua pergunta sobre o que me fez parar o desenvolvimento do kernel, respondi? Acho que explicar minhas motivações ajudaria a dizer por quê parei.

As respostas dos usuários ainda estavam aí. Se qualquer outra coisa, os usuários tinham mais voz que nunca enquanto eu estava anunciando minha saída do desenvolvimento do kernel.

O desafio intelectual? Bem, isso ainda existia, claro.

A diversão? Sim, isso foi o que morreu. Deixou de ser divertido. No meu anúncio via e-mail, agora bastante público, informando que eu estava caindo fora, expliquei isso resumidamente. O patchset -ck foi por um bom tempo um objeto sem importância, fora do pátio dos refletores principais para meus experimentos. Enquanto o escopo das mudanças aumentou, as melhorias tornaram-se drásticas e foram mais agudamente notadas. Isso levou à mais e mais pessoas me perguntando quando as mudanças seriam fundidas ao mainline. Quando o número de pedidos cresceu, minha resolução para não ser envolvido no mainline diminuiu. Então eu ocasionalmente postei patches como exemplos para a mailing list do kernel. Isso gerou mais interesse e pedidos para eu me envolver com o mainline. Então eu tentei.

Você perguntou antes quais patches -ck se incorporaram ao mainline e eu listei um monte de pequenos patches aleatórios. A magnitude de mudanças nos patches que eu não me envolvi vai bem além dos que eu me envolvi.

APC: Houve algo que foi a "última tacada" para você?

Minha primeira grande rejeição foi o staircase CPU scheduler. Provou-se que era bem melhor em interatividade que o mainline CPU scheduler, mas ultimamente, assim como o mainline CPU scheduler, ele teve casos menores que mostraram que não era perfeito. Naquele tempo, enquanto eu ainda estava o desenvolvendo, a atenção desviou-se do CPU scheduler. A razão dada por Andrew Morton (o mantenedor e segunda e última porta de entrada para o kernel mainline) naquele tempo foi que o kernel tinha assuntos mais urgentes e bugs para tratar.

Claro que tinha. Tinha montes de subsistemas sendo repetidamente reescritos, e era uma quebradeira sem fim. E reescrever subsistemas que funcionam e quebrá-los é bem mais importante que algo que deve melhorar o desktop, certo? Oops, um pouco da minha amargura deslizou aqui. Eu tentarei deixar a emoção de lado e apenas contar o resto da história da forma mais objetiva que puder.

O maior problema foi que simplesmente não existia um modo convincente de provar que o staircase era melhor no desktop. Relatórios de usuários não eram o bastante. Não tinha benchmark algum. Não tinha uma forma de provar que era melhor, e os relatórios de usuários, se algo chateou os mantenedores do kernel, favoreciam a sua falta de objetividade. Eu até tentei escrever um benchmark chamado "Interbench". Note que interatividade não é o mesmo que responsividade (eu tenho um pequeno sumário da diferença, como a vejo, com o código Interbench). Esse código era bem melhor que o Contest, mas mesmo eu podendo demonstrar vantagem com meu scheduler no Interbench, a magnitude de diferenças era difícil senão impossível de extrair baseada nos números brutos gerados pelo Interbench.

Com uma carga de ajuda de William Lee Irwin III (que escreveu a arquitetura principal) eu postei um framework de CPU scheduler plugável, que permitiria incluir no kernel tantos CPU schedulers quanto fossem desejados e escolher na hora do boot qual deles rodar. Eu planejei extender isso para uma seleção no runtime também. Isso se parece bastante com o framework I/O scheduler modular plugável que o kernel do Linux tem atualmente. Foi prontamente recusado por Linus e Ingo (que é o mantenedor do CPU scheduler) por levar à especialização dos CPU schedulers e eles dois preferiram que existisse apenas um CPU scheduler que fosse bom em tudo. Acho que você pode dizer que o CPU scheduller é um esmagador que nozes, e nós, como usuários de desktop, o usamos para esmagar nozes, e eles não queriam que nós escrevêssemos quebradores de nozes para o kernel.

O propósito do Plugsched era simplesmente prover um modo sem suturas para o staircase CPU scheduler ser integrado no kernel mainline. Não me senti confiante sobre a presença de CPU schedulers plugáveis, mas muitas pessoas ainda se sentem e o código ainda é mantido hoje principalmente por Peter Williams.

Junto veio a swap prefetch. Gastei um monte de tempo mantendo e melhorando isso. Foi fundido ao -mm kernel 18 meses atrás e eu o estive apoiando desde então. Andrew, até hoje, não está convencido que isso ajuda em alguma coisa e que isso 'deve' ter consequências negativas em outro lugar. Nenhum bug report ou reclamação de performance esteve por vir nos últimos 9 meses. Eu até escrevi um benchmark que mostrou como funcionava, e consegui até mesmo quantificar! Num hilário retorno Linus me perguntou offlist 'sim, mas isso realmente ajuda?'. Bem, relatórios de usuários e benchmarks não eram o bastante... ainda está incerto no momento mas eles não terão escolha para jogá-lo fora sem que alguém esteja mantendo.

Finalmente o prego no caixão. O Staircase Deadline CPU Scheduler. Inicialmente começando como um projeto paralelo do Staircase CPU Scheduler, eu logo notei que era possível ter excelente interatividade enquanto consertava os terríveis problemas de distribuição (fairness) que um design não distribuído (unfair) tinha. Além do mais, ele de fato melhorou assuntos de interatividade em outros lugares que acabaram sendo problemas de distribuição, e a distribuição é obviamente superior aos servidores e ambientes multi-usuário.

Um monte de usuários e até desenvolvedores do kernel acharam que muitas longas e duradouras reclamações com o mainline e outros schedulers foram consertadas por esse código e praticamente me imploraram para empurrá-lo para o mainline, e outro usuário exigiu que Linus fundisse-o o mais rápido possível como um bugfix. Então eu apoiei o código e consertei-o enquanto problemas foram surgindo, juntamente com muitos bugfixes e melhorias ao longo do caminho.

Então cheguei a um beco sem saída. Um usuário com bastante voz notou que o comportamento não distribuído (unfair) no scheduler mainline era algo que ele veio a antecipar. Uma guerra de flames aconteceu nesse tempo, porque para consertar 100% dos problemas com o CPU scheduler nós tivemos que sacrificar a interatividade em alguns workloads. Não era uma perda dramática de interatividade, mas ela definitivamente estava lá. Ao invés de usar 'bom' para proporcionar o CPU de acordo com o lugar que usuário disse que o sistema operacional estaria, o usuário acreditou que era responsabilidade do kernel adivinhar. Como segue, é um fato que 'adivinhar' significa que não importa o quão duramente nem o quão inteligentemente você faça a CPU scheduler, ela vai dar errado algumas horas. Por mais que se tente adivinhar, piores vão ser os casos menos importantes de mal comportamento.

A opção é sufocar o adivinhamento, ou não adivinhar. A primeira opção significa que você tem uma CPU scheduler que é difícil de modelar, e o comportamento é certo 95% do tempo, tendo fluxo e refluxo na medição de CPU e latência. A última opção significa que não existe adivinhação e o comportamento é correto 100% do tempo... só dá o que você diz que deve dar. Parecia tão absurdamente claro para mim, dado que a interatividade na maior parte do tempo era melhor com o método "fair", e ainda assim os mantenedores exigiram que eu endereçasse isso como um problema com o novo design. Eu neguei. Insisti que nós tínhamos que abrir mão de uma pequena quantia para ganhar tremendamente mais. Um scheduler que era determinístico e previsível e ainda assim interativo é uma opção bem melhor a longo prazo do que o método "hack depois de hack" que estávamos mantendo.

Então fiquei doente. Um deslocamento no meu pescoço ditou que eu deveria ficar deitado de costas por mais ou menos 6 meses. Sim, o desenvolvimento do kernel contribuiu para esse problema. Então eu fui medicado no globo ocular e passei a maior parte dos dias e noites deitado... não tendo nada para pensar, a não ser cozinhar o kernel. Sempre que possível eu voltava ao PC para tentar apoiar o código que eu joguei afora. Eu neguei insistir (budge) no aspecto do equilíbrio (fairness), e continuei tendo isso jogado na minha cara como uma falha inconsertável no design.

Então um dia presumivelmente Ingo decidiu que era uma boa idéia, o caminho a se seguir e... escreveu seu próprio design de framework justo-interativo de scheduling... e teve ajuda de código da pessoa que negou aceitar um comportamento "fair" na minha guerra de flames.

Então eu tive um monte de tempo deitado de costas para refletir o que eu estava fazendo e por quê, e se eu estava caminhando para me lamentar disso daquele ponto em diante. Eu decidi completar o trabalho do Staircase Deadline para ter certeza que era uma referência para comparação, em vez de ter o novo código de CPU scheduler do mantenedor comparado ao velho e pesado scheduler. Então eu desisti para sempre.

APC: Os egos dos desenvolvedores são um problema no desenvolvimento open source em geral?

Eu acho que qualquer problema com qualquer modelo de desenvolvimento tem múltiplos fatores, e ultimamente, são humanos que fazem decisões. Eu não vou comentar sobre os humanos em si.

Se existe qualquer grande problema com o desenvolvimento do kernel Linux é a completa falta de participação dos usuários comuns no processo de desenvolvimento. Você sabe, aqueles que constituem 99,9% da base de usuários do Linux.

A mailing list do kernel é o meio de comunicar-se com os desenvolvedores. Colocando a assertativa docemente, a mailing list do kernel Linux (lkml) é um fórum amedrontador, quando as pessoas se aventuram a postar. A maior parte das pessoas ficam absolutamente apavoradas de postar na lista, temendo que sejam incendiadas por sua inexperiência, por um bug report inapropriado, serem acusadas de estúpidas ou seja lá o que for. E na maior parte do tempo eles estão absolutamente certos. Não existe forma amigável de comunicação com as questões dos usuários comuns que são relacionadas ao kernel. Sim, claro que os desenvolvedores do kernel gostam de diversão, pessoas amigáveis e felizes. Veja uma entrevista com o Linus e preste atenção na forma como ele se encara.

Eu acho que os desenvolvedores do kernel em sua maioria não têm a mínima idéia do quanto os problemas são grandes na área do userspace. Apenas uma brava minoria fica contente em postar para a lkml, e eu continuo tendo usuários que entram em contato pelo IRC, pessoalmente ou por minha própria mailing list dizendo quais são seus problemas. E eles até se tornam exitantes quanto a mim, apesar de eu nunca ter me visto como um desenvolvedor real do kernel.

Pesque nos fórums normais de suporte (o que eu fiz para usuários do Gentoo como um meio de encontrar bug reports frequentes, porque os usuários estavam com medo de me contar) e veja quantas questões óbvias relacionadas ao kernel existem. Eu adoraria pedir a eles todos para floodar a lkml de surpresa com seus relatórios, boots falhos com vários kernels, hardwares parando de funcionar repentinamente, desaparecimento de memória, problemas com o software suspend e seus sacos explodidos pelo laptop, e assim vai.

E aí estão todos os óbvios bug reports. Eles tem medo de mencioná-los. O quão amedrontador você acha que é dizer "minhas tabs do firefox abrem mais lentamente desde do último upgrade do CPU scheduler"? Em contraste, os usuários de enterprise são o oposto. Só assista a cada release do kernel e veja o quão rapidamente algum "$bullshit_benchmark é reduzido a 1% com o patch $Y" é reportado. Veja também o quão rapidamente eles atendem a isso.

APC: O que você está fazendo no seu tempo vago agora, e quais os futuros projetos que você têm planejados?

Eu tinha alguns brinquedos de userspace que estava experimentando (ferramentas de compressão, encoding de video/ferramentas de conversão e algumas outras) que eu pensei que voltaria a mexer. Mas olhar para qualquer código me dá um gosto ruim na boca, então isto não está mais acontecendo.

Minha paixão atual é aprender japonês. É divertido, é um desafio intelectual imenso, vai me permitir eventualmente entender sua linguagem nativa (histórias curtas, cinema, mangá e anime) e vem sem cordas incluídas. Eu nunca soube realmente qual hobby que vou terminar adotando, mas sempre torno-me completamente absorto em qualquer coisa que seja.

Share this post

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

  • Create New...

Important Information

By using this site you accept our Terms of Use and Privacy Policy. We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.