Quotes of the week [LWN.net]

As the situation exists today, implementations for many 'high-level' programming languages operate in competition with the kernel. Garbage Collection without Paging demonstrated a 218x improvement in latencies and a 41x improvement in throughput by integration of GC and the kernel's paging system (requiring a patch to the Linux kernel). Intelligent, rational people often balk at the notion of a high-level language-as-an-OS because GC, in their experience, introduces so many performance issues - never mind that GC has never had a fair, portable opportunity to leverage the hardware features because the OS kernel is hogging them!

-- "dmbarbour"

No matter how hard I try, I always read this as "DAMAGED". Which I can't help but imagine subliminally influences the reader's opinion of the patches.

Of course I am excellent at naming things, see "chunkfs" and "relatime". But some ideas for naming various concepts in this patch:

D_MIGHT_MOUNT
D_CHILL_OUT
D_ITS_COMPLICATED

-- Valerie Aurora

Quite frankly, if somebody has something in "next" (and really meant for the _next_ merge window, not the current one) that is marked for stable, I think that shows uncommonly bad taste. And that, in turn, means that the "stable" tag is also very debatable. It clearly cannot be important enough to really be for stable if it's not even being aggressively pushed into the current -rc.

-- Linus Torvalds

So changing kernel interfaces that get exported to user space is always a disaster. Anybody who _designs_ for that kind of disaster shouldn't be participating in kernel development, because they've shown themselves to be unable to understand the pain and suffering.

-- Linus Torvalds

Hello NSA. I'm the first person ever banned from linux-kernel. I was banned for spewing hackish off-topic stuff like a working stack machine interpreter daemon, "Why the Plan 9 C compiler doesn't have asm("")", and a packages-friendly internationalization of the file names tree. Appended below is a trivial shell function that gets rid of make.

-- Rick Hohensee is back (thanks to Valerie Aurora)

Dear Martin,

Are you from the same HTC mentioned here?

[htc-willfully-violates-gpl-t-mobiles-new-g2-android-phone]

If so, please ask again in 90-120 days. Until then, you're on your own.

-- Matt Mackall

Quotes of the week

Posted Oct 14, 2010 5:22 UTC (Thu) by neilbrown (subscriber, #359) [Link] (1 responses)

> Anybody who _designs_ for that kind of disaster shouldn't be participating in kernel development,

Not sure I agree with. Rather people who don't design for it should be questioned.

The reality is that we all make mistakes. So we have 3 options.

1/ Keep new designs out of mainline until they are close enough to perfect.
2/ Support broken designs in mainline indefinitely
3/ Plan for the inevitable and ensure there is a mechanism for removing bad stuff with minimal pain.

1 is discouraged by the 'upstream first' policy that is widely encouraged.
3 is discouraged by Linus, it seems.
That leaves 2, an obvious default, but not a pleasant one.

We do have a rough mechanism for deprecating features, but that is only part of the answer. I would really like to be able to mark a feature so that a developer needs to be consciously aware that it is experimental before using it. And I don't think 'CONFIG_EXPERIMENTAL' really serves that purpose. I'm not sure what a good answer is though.

It should be noted that Linus' comment is taken a little out of context - it is a very broad statement made about a very specific context (which is not atypical for Linus :-) It may be that he is right in that context without being right in general.

Quotes of the week

Posted Oct 14, 2010 15:48 UTC (Thu) by bronson (subscriber, #4806) [Link]

or: 4/ Plan for the inevitable and ensure there is a mechanism for adding functionality without removing or breaking anything.

In other words, try to anticipate what people will need in 3 years and make sure you can easily accommodate it. Don't use bitfields (or, if you do, make sure you leave more than a few bits free).

That's my interpretation, seems consistent to me.

Agreed, CONFIG_EXPERIMENTAL doesn't mean much. I'm not sure it can be improved, though, because pretty much any alternative would fall into the same "technical solution to a social problem" trap. We application programmers love new features, we will adopt them as soon as we can, and we will howl if they break. Alas.

Quotes of the week

Posted Oct 14, 2010 8:10 UTC (Thu) by pebolle (guest, #35204) [Link] (4 responses)

> Rick Hohensee is back (thanks to Valerie Aurora)

That probably doesn't mean what a first reading suggests ...

Quotes of the week

Posted Oct 14, 2010 11:56 UTC (Thu) by nix (subscriber, #2304) [Link] (3 responses)

Val found him on BitTorrent and gave him some space to execute again. (He's written in Forth, of course.)

Quotes of the week

Posted Oct 14, 2010 17:33 UTC (Thu) by tdwebste (guest, #18154) [Link] (2 responses)

<quote>He's written in Forth, of course</quote>

You mean, his posting is written in Forth?

I definitely need to study the forth language so that I can correspond with him in Forth.

A good example of obfuscated writing. The extracting the functional purpose and the concealed message is a recreational challenge for readers.

Perhaps a really cool way to communicate secret messages.
Thus the subject title "HEY NSA" of this broadcast message. Perhaps the whole purpose of this broadcast message is to reliably share a cryptographic key.

Quotes of the week

Posted Oct 14, 2010 21:16 UTC (Thu) by naptastic (guest, #60139) [Link] (1 responses)

I got almost halfway through his letter before giving up. I *thought* I was reading a letter from a hacker about his ideas for a new OS, but I'm not sure. Are we being punked? What's this about, really?

Quotes of the week

Posted Oct 17, 2010 6:22 UTC (Sun) by CChittleborough (subscriber, #60775) [Link]

Googling Rick Hohensee indicates that he is a real person, though not completely well.

GC

Posted Oct 14, 2010 11:08 UTC (Thu) by aanno (subscriber, #6082) [Link] (4 responses)

This seems to be a two-way barrier: kernel people don't understand why you want to use GC, and higher language people don't understand why it is not supported by the OS. It's funny *and* distracting.

The complete text this quote comes from is about cache locality and programming language (constructs). I wonder if immutable data structures would be that much better than mutable OO Objects (as e.g. ghc/haskell is designed to use immutable data structures in the first place, but still needs a GC in his runtime support). But it is an interesting subject.

AFAIK, at present there is simply no good idea how to integrate a reusable GC with the OS. Perhaps there should be more research in this direction...

GC

Posted Oct 14, 2010 12:51 UTC (Thu) by droundy (guest, #4559) [Link] (3 responses)

The trouble with GC seems to be that there is so much language-specific information that could affect its optimization, e.g. knowing which memory involves points. Pessimistic GC is leaky on 32-bit systems, besides being slow. How much information need a language runtime pass to the kernel? (And what to do about finalizers, soft pointers, etc.)

On the other hand, if there's *something* the kernel could do to help GC, that'd be great.

GC

Posted Oct 14, 2010 13:44 UTC (Thu) by juanjux (guest, #11652) [Link]

IMNAEIGCS (I'm not an expert in garbage collectors), but for what I read in the article in the linked article a lot of the problems come from the GC collection suddently reactivating al swapped out pages from a process, which can be certainly painful.

GC

Posted Oct 15, 2010 19:33 UTC (Fri) by kingdon (guest, #4526) [Link] (1 responses)

The patches in the paper don't get the kernel nearly that involved. They add a system call called vm_relinquish which means (roughly) "please swap out this page soon" and a way for the process to say "please send me a real-time signal when you're about to page out one of my pages". There is a version of their patch here (see also description). I also see a vm_getswaprate system call which lets the process ask how much it is paging. I think that's about it (the patch also includes Scott Kaplans lightweight version of Rik van Riels reverse mapping patch but unless I'm mistaken that was long ago merged into Linux).

GC

Posted Oct 17, 2010 15:57 UTC (Sun) by i3839 (guest, #31386) [Link]

Also, the quoted performance numbers are compared to other garbage
collectors, not to normal explicit memory allocation. And under heavy memory pressure when swapping happens. All in all less interesting that it seemed to be at first glance.