Interview:
Linus Torvalds – I don't read code any more
with
Glyn Moody, 13 November 2012, 15:16
Bài
được đưa lên Internet ngày: 13/11/2012
Lời
người dịch: Linus Torvals điểm lại những thời kỳ khó
khăn trong phát triển nhân Linux. Đã từng có thời kỳ,
để nhân Linux làm việc trên 8 CPU là một điều khó vượt
qua. “Bây giờ trên máy tính để bàn, 8 và 16 CPU là
thường; đã quen là chúng tôi đã lo lắng mở rộng phạm
vi tới 8 CPU, bây giờ thì điều đó là trò chơi trẻ con
rồi”, và nhiều khó khăn khác, đặc biệt với các
trình điều khiển thiết bị, một thứ mà ông cho là
nhàm chán và hiện chiếm hầu hết các công việc của
nhân Linux. “Hơn một nửa của nhân chỉ là các trình
điều khiển, và vì thế tất cả những điều thông minh
thú vị lớn mà chúng tôi làm, cuối cùng nó làm nhạt đi
khi so với tất cả công việc chúng tôi chỉ làm để hỗ
trợ các phần cứng mới”. Dễ hiểu vì sao những ai
có khúc mắc về trình điều khiển, khi không làm đúng
qui trình ngược lên dòng trên để về với dự án nhân
Linux của Linux Foundation của Linus Torvalds, mỗi lần có
phiên bản nhân mới. Xem các phần [01], [02], [03], [04].
Tôi có đủ may mắn
để phỏng vấn Linus hoàn toàn sớm trong lịch sử của
Linux - ngược về năm 1996, khi tôi vẫn còn sống tại
Helsinki (bạn có thể đọc các kết quả cuộc gặp trong
bài viết cũ trên Wired).
Đó từng là ở một thời điểm quan trọng đối với
ông ta, cả về việc cá nhân - đứa con đầu lòng của
ông đã sinh ra khi đó - và về sự nghiệp của ông ta.
Ông từng ra nhập công ty thiết kế chip Transmeta, một
động thái đã không thực sự thuận tiện, nhưng đã cho
phép ông định vị lại ở Mỹ, nơi ông sống hôm nay.
Điều đó làm cho
những chuyến đi tới châu Âu của ông đôi lúc là hãn
hữu, và tôi đã tận dụng được thực tế rằng ông đã
nói chuyện tại LinuxCon Europe 2012 gần đây tại Barcelona
để phỏng vấn ông một lần nữa, rà soát lại những
thời điểm quan trọng cho nhân Linux và cộng đồng của
nó kể từ lần nói chuyện trước.
Glyn Moody: Quay
lại hơn một thập kỷ rưỡi trước, ông thấy những sự
kiện chính nào trong phát triển nhân?
Linus Torvalds:
Một điều lớn lao đối với tôi là tất cả công việc
mở rộng về phạm vi mà chúng tôi đã làm. Chúng tôi đã
đi từ OK trên 2 hoặc 4 CPU tới điểm nơi mà về cơ bản
bạn có theer ném ra 4.000 - bạn sẽ không mở rộng phạm
vi được tuyệt vời, nhưng hầu hết thời gian điều đó
không là nhân mà là sự tắc nghẽn. Nếu tải công việc
của bạn là thứ gì đó lành mạnh thì thực sự chúng
tôi mở rộng phạm vi thực sự tốt. Và điều đó đã
cần nhiều nỗ lực.
SGI đặc biệt đã
làm việc nhiều trong việc mở rộng phạm vi qua vài trăm
CPU. Những bản vá ban đầu của chúng có thể chỉ không
trộn được. Đã từng không có cách gì để chúng tôi
có thể đưa công việc mà chúng tôi đã làm và sử dụng
nó trong một PC thông thường vì chúng đã bổ sung tát cả
những hạ tầng này vào công việc trên hàng ngàn CPU. Đó
từng là cách quá đất để làm khi bạn đã chỉ có một
số ít.
Tôi từng sợ trong
một thời gian dài rằng chúng tôi có thể có nhân hiệu
năng cao cho các máy tính lớn, và mã nguồn có thể tách
bạch khỏi nhân thông thường. Mọi người đã làm việc
nhiều chỉ để chắc chắn rằng chúng tôi đã có một
kho mã nguồn sạch sẽ nơi mà bạn có thể nói vào lúc
biên dịch, này, tôi muốn nhân làm việc cho 4.000 CPU, và
nó tạo ra mã nguồn cho điều đó, và cùng lúc, nếu bạn
nói không, thì tôi muốn nhân đó làm việc trên 2 CPU, với
cùng mã nguồn đó biên dịch.
I
was lucky enough to interview Linus quite early in the history of
Linux – back in 1996, when he was still living in Helsinki (you can
read the fruits of that meeting in this old Wired
feature.) It was at an important moment for him, both personally
– his first child was born at this time – and in terms of his
career. He was about to join the chip design company Transmeta, a
move that didn't really work out, but led to him relocating to
America, where he remains today.
That
makes his trips to Europe somewhat rare, and I took advantage of the
fact that he was speaking at the recent LinuxCon
Europe 2012 in Barcelona to interview him again, reviewing the
key moments for the Linux kernel and its community since we last
spoke.
Glyn
Moody: Looking back
over the last decade and half, what do you see as the key events in
the development of the kernel?
Linus
Torvalds: One big
thing for me is all the scalability work that we did. We've gone from
being OK on 2 or 4 CPUs to the point where basically you can throw
4,000 [at it] – you won't scale perfectly, but most of the time
it's not the kernel that's the bottleneck. If your workload is
somewhat sane we actually scale really well. And that took a lot of
effort.
SGI
in particular worked a lot on scaling past a few hundred CPUs. Their
initial patches could just not be merged. There was no way we could
take the work they did and use it on a regular PC because they added
all this infrastructure to work on thousands of CPUs. That was way
too expensive to do when you had only a couple.
I
was afraid for the longest time that we would have the
high-performance kernel for the big machines, and the source code
would be separate from the normal kernel. People worked a lot on just
making sure that we had a clean code base where you can say at
compile time that, hey, I want the kernel that works for 4,000 CPUs,
and it generates the code for that, and at the same time, if you say
no, I want the kernel that works on 2 CPUs, the same source code
compiles.
Từng là thứ gì đó
mà trong sự hồi tưởng về quá khứ thực sự là quan
trọng vì nó thực sự làm cho mã nnguồn tốt hơn nhiều.
Tất cả nỗ lực mà SGI và những người khác bỏ ra
trong việc thống nhất mã nguồn, thực sự nhiều mã
nguồn từng được làm sạch - điều này không làm được
cho một trăm CPU, nên chúng tôi cần làm sạch sao cho nó
làm việc được. Và nó thực sự đã làm cho nhân được
duy trì nhiều hơn. Bây giờ trên máy
tính để bàn, 8 và 16 CPU là thường; đã quen là chúng
tôi đã lo lắng mở rộng phạm vi tới 8 CPU, bây giờ thì
điều đó là trò chơi trẻ con rồi.
Nhưng cũng có những
điều khác nữa. Chúng tôi đã bỏ ra nhiều năm một lần
nữa ở một đầu khác, nơi mà điện thoại mà mọi
người từng có ý thức rõ rằng họ đã có những điều
không hay, đặc biệt ở phía của ARM, để cố gắng tiết
kiệm năng lượng. Chúng tôi đã bỏ ra nhiều năm làm
quản lý năng lượng nói chung, làm dạng việc y hệt -
thay vì có những hack quản lý năng lược chuyên cho ARM,
và một ít các thiết bị mà các máy điện thoại mọi
người quan tâm, chúng tôi đã cố gắng làm cho nó đi
xuyên khắp nhân. Và điều đó mất 5 năm để làm việc
với quản lý năng lượng, vì điều đó xuyên suốt toàn
bộ phổ.
Hoàn toàn thường
xuyên khi bạn bổ sung một thiết bị, điều đó không
ảnh hưởng tới bất kỳ phần còn lại nào của nhân,
nhưng quản lý năng luonwgj từng là một thứ ảnh hưởng
tới tất cả hàng ngàn trình điều khiển thiết bị mà
chúng tôi có. Nó ảnh hưởng tới chức năng cốt lõi,
như tắt CPU, và ảnh hưởng tới lịch trình, nó ảnh
hưởng tới VM, nó ảnh hưởng tới mọi thứ.
Nó không chỉ ảnh
hưởng tới mọi thứ, nó có tiềm năng làm hỏng mọi
thứ mà làm cho nó rất đau đớn. Chúng tôi đã bỏ ra
nhiều thời gian chỉ để tiến 2 bước, lùi 1 bước vì
chúng tôi đã làm được một cải tiến mà từng là một
cải tiến rõ ràng, nhưng nó làm hỏng các máy. Và vì thế
chúng tôi đã phải lùi một bước chỉ để sửa các máy
mà chúng tôi đã làm hỏng.
Lý
tưởng mà nói, mỗi phiên bản, hầu hết chỉ là công
việc về trình điều khiển. Nó là dạng làm chán nản
theo ý nghĩa chẳng có gì thú vị về cơ bản trong một
trình điều khiển cả, nó chỉ là sự hỗ trợ cho một
chipset khác hoặc thứ gì đó, và cùng lúc dạng bánh mỳ
và bơ của nhân. Hơn một nửa của nhân chỉ là các
trình điều khiển, và vì thế tất cả những điều
thông minh thú vị lớn mà chúng tôi làm, cuối cùng nó
làm nhạt đi khi so với tất cả công việc chúng tôi chỉ
làm để hỗ trợ các phần cứng mới.
It
was something that in retrospect is really important because it
actually made the source code much better. All the effort that SGI
and others spent on unifying the source code, actually a lot of it
was clean-up – this doesn't work for a hundred CPUs, so we need to
clean it up so that it works. And it actually made the kernel more
maintainable. Now on the desktop, 8 and 16 CPUs are almost common; it
used to be that we had trouble scaling to 8, now it's like child's
play.
But
there's been other things too. We spent years again at the other end,
where the phone people were so power conscious that they had ugly
hacks, especially on the ARM side, to try to save power. We spent
years doing power management in general, doing the kind of same thing
– instead of having these specialised power management hacks for
ARM, and the few devices that cellphone people cared about, we tried
to make it across the kernel. And that took like five years to get
our power management working, because it's across the whole spectrum.
Quite
often when you add one device, that doesn't impact any of the rest of
the kernel, but power management was one of those things that impacts
all of the thousands of device drivers that we have. It impacts core
functionality, like shutting down CPUs, it impacts schedulers, it
impacts the VM, it impacts everything.
It
not only affects everything, it has the potential to break everything
which makes it very painful. We spent so much time just taking two
steps forward, one step back because we made an improvement that was
a clear improvement, but it broke machines. And so we had to take the
one step back just to fix the machines that we broke.
Realistically,
every single release, most of it is just driver work. Which is kind
of boring in the sense there is nothing fundamentally interesting in
a driver, it's just support for yet another chipset or something, and
at the same time that's kind of the bread and butter of the kernel.
More than half of the kernel is just drivers, and so all the big
exciting smart things we do, in the end it pales when compared to all
the work we just do to support new hardware.
Dịch: Lê Trung Nghĩa
Không có nhận xét nào:
Đăng nhận xét
Lưu ý: Chỉ thành viên của blog này mới được đăng nhận xét.