How Google Uses Linux 155
postfail writes 'lwn.net coverage of the 2009 Linux Kernel Summit includes a recap of a presentation by Google engineers on how they use Linux. According to the article, a team of 30 Google engineers is rebasing to the mainline kernel every 17 months, presently carrying 1208 patches to 2.6.26 and inserting almost 300,000 lines of code; roughly 25% of those patches are backports of newer features.'
Re:Release the patches already (Score:5, Informative)
Try iotop.
http://guichaz.free.fr/iotop/ [guichaz.free.fr]
Re:Release the patches already (Score:4, Informative)
Togh (Score:3, Informative)
Google does not distribute the binaries, so they are not obliged to publish the source.
Re:Is it worth it? (Score:1, Informative)
Wait, what? Has Google seriously never heard of vm.overcommit_memory [kernel.org]?
Re:A New Culture (Score:5, Informative)
Funnily enough the roads were there before the cars.
Re:Togh (Score:1, Informative)
I think TFA also tries to notice how stupid is to base all your work in a old kernel because it's supposed to be the well-know stable release used in the organization, and then waste lots of human resources into backporting features from newer kernels. This is what Red Hat and Suse used to do years ago, and avoiding it is the main reason why Linus' set up the new development model. Google could learn from the distros, they probably can use all those human resources to follow more closely the kernel development. Switching to git will probably help a lot.
Re:Does Google give coade back (Score:5, Informative)
Yes, they do. Since they use older kernels and have... unique... needs, they aren't a huge contributor like RedHat, but they do a lot.
During 2.6.31, they were responsible for 6% [lwn.net] of the changes to the kernel.
Re:Does Google give coade back (Score:1, Informative)
During 2.6.31, they were responsible for 6% [lwn.net] of the changes to the kernel.
That's 6% of non-author signoffs. It's not 6% of changes. I'm not saying they don't contribute, but the manner of their contribution isn't what your suggesting.
Re:Does Google give coade back (Score:3, Informative)
Re:Does Google give coade back (Score:5, Informative)
Andrew has been doing a large amount of kernel work for some time now, before his employment with Google. Note that the 6% figure is under non-author signoffs - people that patches went through, instead of people who actually authored them. Heck, even I submitted a patch that went through Andrew once (and I've submitted like 5 patches to the kernel). Andrew does a lot of gatekeeping for the kernel, but he doesn't write that much code, and he certainly doesn't appear to be committing code written by Google's kernel team under his name as a committer.
Google isn't even on the list of actual code-writing employers, which means they're under 0.9%. I watched a Google Tech Talk about the kernel once (I forget the exact name) where it was mentioned that Google was (minus Andrew) somewhere in the 40th place or so of companies who contribute changes to Linux.
Re:Does Google give coade back (Score:5, Informative)
Google is responsible for a tiny part of kernel development last I heard, unfortunately.
I don't know that much about google's private modifications, but the question of "what to give back" does not always have a clear default answer. I've modified lots of OSS in the past and not given it back, simply because my best guess was that I am the only person who will ever want feature x. There's no point in cluttering up mailing lists or documentation with something extremely esoteric. It's not because I'm lazy or selfish or greedy -- sometimes the right answer is to just keep things to yourself. (Of course, there are times when I've modified something hackishly, and had been too lazy or embarrassed to send it back upstream :)
Perhaps google answers this question in a different way than others would, but that doesn't necessarily conflict with "the spirit of OSS", whatever that might be.
Re:Does Google give coade back (Score:4, Informative)
By that I meant "developed for Google, useful to other people".
We can divide Andrew's potential kernel work into 4 categories:
Points 1 and 2 can be considered a result of Andrew's employment at google. Points 3 and 4 would happen even if he weren't employed at Google. From my understanding, the vast majority of Andrew's work is point 4 (that's why he's listed under non-author signoffs as 6%, along with Google). Both Andrew's and Google's commit-author contributions are below 0.9%.
So what we can derive from the data in the article, assuming it's accurate, is:
So no, Google doesn't contribute much to the kernel. Having Andrew on board gives them some presence and credibility in kernel-land, but they don't actually author much public kernel code. Hiring someone to keep doing what they were already doing doesn't make you a kernel contributor.
DTrace (Score:2, Informative)
I. Want. This.
DTrace code:
#pragma D option quiet
io:::start
{
@[args[1]->dev_statname, execname, pid] = sum(args[0]->b_bcount);
}
END
{
printf("%10s %20s %10s %15s\n", "DEVICE", "APP", "PID", "BYTES");
printa("%10s %20s %10d %15@d\n", @);
}
Output:
# dtrace -s ./whoio.d
^C
DEVICE APP PID BYTES
cmdk0 cp 790 1515520
sd2 cp 790 1527808
More examples at:
http://wikis.sun.com/display/DTrace/io+Provider
Re:The Win32 Way (Score:1, Informative)
Unless you run Linux!
" By default, Linux follows an optimistic memory allocation strategy. This
means that when malloc() returns non-NULL there is no guarantee that the
memory really is available. This is a really bad bug. In case it turns
out that the system is out of memory, one or more processes will be
killed by the infamous OOM killer. In case Linux is employed under cir-
cumstances where it would be less desirable to suddenly lose some ran-
domly picked processes, and moreover the kernel version is sufficiently
recent, one can switch off this overcommitting behavior using a command
like:
# echo 2 > /proc/sys/vm/overcommit_memory
"
Re:A New Culture (Score:3, Informative)
Fair chance you were just joking, but I figure, why not go on a info dump?
Re:Togh (Score:3, Informative)
If you read [lwn.net] about [lwn.net] them, you'd know that devtmpfs just populates
Now during init, udev's job is to parse udev rules and add user configuration plus fix the permissions of nodes in
In essence, devtmpfs's job is to allow a bootable system without the need to maintain a static
devfs was bad, really bad because there was no naming system back then, and every driver did something different causing utter chaos (which led to different distros patching the kernel in different ways to change the node names). Now there's uniformity, and the kernel knows what to call the basic device nodes created by the drivers.
Re:Solaris (Score:3, Informative)
Pick your poison.