Quotes of the week [LWN.net]

Every new configuration combination is a new situation that competes testing wise with the others.

There's a stigma rightfully attached to out-of-tree patches, which roughly amounts to "people ought to submit patches upstream, we shouldn't have to support or care about out-of-tree patches". But that only works if the responses to patch submissions are either "No, because you need to fix X, Y, and Z", or "No, because your use case is better served by this existing mechanism already in the kernel", rather than "No, your use case is not valid".

— Josh Triplett

If you are using glibc and GNU tools it isn't going to work, but long ago tools were written which just did the job they were supposed to do at the time and were small and tidy. Programmers were expected to use shell scripts to combine them for harder jobs rather than be the one person a year who invoked gnu-wibble --format-sideways-while-singing --tune=waltzing-matilda

— Alan Cox

And as for announcing [long-term stable releases] ahead of time, I'm never going to do that again, the aftermath was horrid of people putting stuff that shouldn't be there. Heck, when people know about what the enterprise kernels are going to be, they throw stuff into upstream "early", so it's a well-known pattern and issue.

— Greg Kroah-Hartman

to post comments

Quotes of the week

Posted May 9, 2014 16:14 UTC (Fri) by lacos (guest, #70616) [Link] (5 responses)

Alan Cox is right about duct-taping small tools together in shell scripts -- up to a point. The point (or at least one point) where it breaks down is loops in shell scripts. Fork+exec performance is abysmal. If you can choose between a C program that has the loop in question built-in, and a shell script loop that invokes another C program once per iteration, you always pick the first -- or even write it.

Simple example, the 'date' utility. Compare:

for ((K=0; K < 10 * 1000; K++)); do
date -d now
done

vs.

yes now | head -n 10000 | date -f -

The first takes:

real 0m17.143s
user 0m4.181s
sys 0m13.899s

on my laptop, while the latter takes

real 0m0.126s
user 0m0.042s
sys 0m0.086s

(Non-scientific measurement, clearly.)

Minimizing round-trips has always been important (ie. moving the loop logic as close to the data as possible), but I feel fork/exec performance has worsened over the years. (I have no hard evidence.)

Quotes of the week

Posted May 9, 2014 17:43 UTC (Fri) by nevets (subscriber, #11875) [Link] (4 responses)

> I feel fork/exec performance has worsened over the years. (I have no hard evidence.)

Could be.

As task_struct has increased over the years, the initialization and copying of it takes a bit longer too. Not sure how much that really adds, but I'm sure there's other places that caused it to suffer as well.

Quotes of the week

Posted May 9, 2014 18:22 UTC (Fri) by khim (subscriber, #9252) [Link] (3 responses)

Both fork(2) and exec(2) are plenty fast on Linux. What's slow is ld-linux.so. And it's slow because programs which it's supposed to start are written in very suboptimal way. Huge amount of code is executed before your main() is invoked.

Quotes of the week

Posted May 15, 2014 17:29 UTC (Thu) by ssokolow (guest, #94568) [Link] (2 responses)

I'm always game for spending time improving the performance of my creations.

Can you recommend any reading materials on minimizing this overhead?

Quotes of the week

Posted May 16, 2014 10:12 UTC (Fri) by khim (subscriber, #9252) [Link] (1 responses)

Drepper's How To Write Shared Libraries is good place to start. Large amount of data and text don't affect startup (if they are not used) but relocations and constructors (if they are used) must be processed before your program can even start—and that work is usually pure waste since most tables are never used, variables are never accessed, etc.

People don't optimize libraries and programs WRT their startup time—is it any wonder that it becomes slow?

Quotes of the week

Posted May 17, 2014 13:42 UTC (Sat) by ssokolow (guest, #94568) [Link]

Thanks. I'll give that a read as soon as I can spare the time to really absorb it.