LWN.net comments

Trusting the hardware too much

Felix.Braun — 2012-02-17T07:53:38+00:00

[O]ne must treat the hardware as if it were a clever and willful dog. With some effort, it can be made to perform impressive tricks, but, given a moment of inattention, it will snag your dinner from the grill and hide under the couch.

May I suggest this as the quote of the year?

FOSDEM: The Wayland display server

JohnLenz — 2012-02-17T07:22:54+00:00

Actually, that isn't correct. The protocol includes direct support for copy/paste and drag/drop. See this old thread for the rationale to add it directly to the protocol. You can notice the copy/paste stuff in the current protocol description.

Linux support for ARM big.LITTLE

hamish — 2012-02-17T06:29:50+00:00

It would be good to be able to have some generic logic available in the kernel - as a default, with knobs to take control from userspace if there is a policy daemon available.

Perhaps something like a blending of the scheduler with a cpu-freq governor:
A busy cpu is interpreted as a signal to increase the frequency, but if the frequency cannot be increased (due to big.LITTLE or a package power usage limitation, or something else I cannot envisage) but there are other cpus that have faster speeds still available then one (or more) processes can be selected to migrate cpus (but not necessarily all the processes from the slow cpu). (And I have not thought about how to decide to migrate back to the slower cpu either ...)

Obviously, this would not suit all workloads, but would provide a good starting point and seems like it could be of use in other asymmetric scenarios.

Sure, race-to-idle is possibly only applicable to current hardware (and maybe only batch jobs), but I also think that similar principles are likely to apply to user-perceived latencies during interactive tasks - especially if you can powerdown what is likely to be a power hungry core and keep the residual activity running on the slow core.

Linux support for ARM big.LITTLE

dlang — 2012-02-17T05:17:26+00:00

right, but this sort of decision is too system specific to put into the kernel. Instead you want to have a userspace daemon decide what processors to use.

If the load if heavy enough, you want to use every processing cycle you have available. If the load is a little lighter, you may turn off some of the slow cores to save power (if your "race to idle" logic applies to the use case and you really will go idle), let the load drop some more and you will want to turn on the slow cores and turn off a fast one, etc

the possible combinations are staggering, and include user policy trade-offs that can get really ugly

race-to-idle is not an absolute, it's an observation that at the current time, the power efficiency of CPUs is such that for a given core, you are more efficient to race-to-idle than to reduce your clock speed. But when you then compare separate cores with different design frequencies, the situation may be very different.

remember that you can run a LOT of low-power cores for the same power as a single high-power core, enough that if your application can be parallelized well you are far better off with 100 100MHz cores than one 1GHz core, both in the amount of power used and the amount of processing you can do.

race-to-idle also assumes that as soon as you finish the job you can shut down. This is very true in batch job situations, but most of the time you don't really go into your low-power mode immediatly, instead you run idle for a little bit, then shift to a lower power mode, wait some more, etc (and or much of this you keep the screen powered, etc), all these things need to be taken into consideration for a particular gadget when you are deciding what your best power strategy is going to be.

Linux support for ARM big.LITTLE

hamish — 2012-02-17T05:06:54+00:00

This (very appealing) simplification doesn't take into account the race to completion - so you might end up using more total power staying on the slow cpu than would have been used up by bouncing the process to the fast cpu.

I suppose a large part of this depends on the power usage profile of the two speed cpu's - if the power used by the slow cpu running at full speed is the same or less than the power used by the fast cpu (when the fast cpu is at a cpu freq that produces equivalent numbers of MIPS) then this pattern could be used.

There still would need to be some way to work out that a process could benefit from a lower latency - and allow it to use the higher speeds available on the fast cpu.

Wayland - Beyond X (The H)

Cyberax — 2012-02-17T05:02:11+00:00

No, obscure old libraries are unlikely to be ported to Wayland and would just run inside a hosted X-server.

Alternatively, they can fall back to a generic VNC-like protocol.

Quotes of the week

ras — 2012-02-17T04:54:42+00:00

This is the first time I have read criticism of grub2 configuration. When I realised grub2's configuration system was script that wrote a script that is executed to produce a configuration file that is also a script executed by the grub2 interpreter, I thought I had fallen into a rabbit hole. I was left wondering if everyone else though this was insane, or was I the insane one. It's nice to find out it's not just me.

> I expect Lennart Pottering will announce his Grub2 replacement any day now.

The interface you are supposed to use to configure Grub2 (/etc/default/grub) is simple enough - much simpler than the old grub. However should you not like the /boot/grub/grub.conf it produces, you have to understand the monster underneath and the largely undocumented grub2 modules it uses.

I gather systemd is much the same. It replaces the system V init scripts something much simpler on the surface, but whereas the scaffolding that runs the system V init scrips could be understood in a day or so, underneath those simple systemd scripts lurks another very large monster.

RSA keys not as random as they should be (The H)

fredcadete — 2012-02-17T03:45:33+00:00

Maybe those keys were all generated under Debian when it had that openssl bug.

Day: A New Approach to GNOME Application Design

bronson — 2012-02-17T03:31:22+00:00

I think this is it...

https://bugzilla.redhat.com/show_bug.cgi?id=748843

I'm running Radeon but not Intel so this might not be related to the problem I'm seeing. That said, I'm not too interested in this bug... I couldn't get Fedora to recognize my wireless adapter so I'm running XFCE on Mint. Worked perfectly out of the box, super stable.

I'll try Fedora again in a release or two.

Lea: The Unity design process (and how you can play a part in it)

richo123 — 2012-02-17T03:24:57+00:00

From the log of M. "Bling" Shuttleworth

Unity Workflow Diagram

Problem: Users hate the Unity interface and are migrating in large numbers to cinnamon and other desktops.

Case Studies: Jim hates having to navigate though "lenses" and "HUDS" surrounded by blaring bling. He dislikes the desktop being configurable only as much as developers deem appropriate. Kate loves the simple intuitive and attractive new cinnamon interface that works a lot like Gnome 2 used to and is already very configurable.

Potential Solution: Concede users have a point and abandon ship.

SABDFL Solution: Write another blog entry spinning Unity some more. Disregard disgruntled "overly conservative" users on the theory the sheep will come home sooner or later because I have so much money.

Intel's upcoming transactional memory feature

deater — 2012-02-17T03:21:18+00:00

I'm usually not one to like results done purely in a simulator either, but this work was likely done in 2008... what actual hardware could they have used to do the experiment? I was just impressed they tackled an actual real-world example like the Linux kernel and not just some set of microbenchmarks.

It will be interesting to see similar work re-done now that actual implementations exist of TM. I just don't think anyone has ever shown performance benefits from TM that couldn't also be realized with well-written traditional locking.

Wayland - Beyond X (The H)

jschrod — 2012-02-17T03:14:01+00:00

^H happens when network transparency layer misbehaves.

I really thought you had something to tell.

*PLONK*

Quotes of the week

bronson — 2012-02-17T03:07:25+00:00

> On an EFI system with Matt Fleming's work you can boot a kernel direct from the firmware.

Wait, what? Really? Oh man, *want*.

Quotes of the week

bronson — 2012-02-17T03:01:58+00:00

Grub2 became the default in Squeeze a year ago, Verne just got it in Nov. Not too far apart.

I totally understand why Fedora held off... The configuration for Grub2 is so unbelievably obtuse that its authors need to hang their heads in shame. It actually makes init scripts look sane. I expect Lennart Pottering will announce his Grub2 replacement any day now.

Wayland - Beyond X (The H)

jschrod — 2012-02-17T02:30:49+00:00

khim *is* giving them a bad reputation.

If they don't want that, maybe, they should start to get involved in the discussion on one of the important, if not the most important, Linux news sites? Life's a bitch and all that...

Trusting the hardware too much

asimkadav — 2012-02-17T02:09:55+00:00

Thanks for pointing that out Jon! The one you reported was an issue with our new i2c support - I just fixed them across all results. Most commonly, false positive arise due to counters that we fail to detect though. There were about 8% false positives or so when we reported the results thoroughly for 2.6.18 kernel. There are still about 800+ bugs out there, and many of them occur in larger groups (although there are many one off bugs as well).

Wayland - Beyond X (The H)

obi — 2012-02-17T02:09:52+00:00

does that mean you'd have to write a "rendering proxy" for every rendering API that could possibly be used? ie. cairo, opengl, whatever obscure graphics library a future Wayland client might decide to use?

Wayland - Beyond X (The H)

jschrod — 2012-02-17T02:09:44+00:00

I *am* using X network transparancy daily, and I haven't bothered to participate in discussions here since no Wayland developers are involved, it's not worth it.

But then, I respond to an obvious troll named bloopletech, so maybe I should have done so. Congratulations to your trolling, sir. You are a good one.

Open webOS governance model described

jmalcolm — 2012-02-17T01:54:59+00:00

Well, WebOS is actually out there in the wild on the TouchPad tablets and several phones. So, it is already a whole lot more successful than Meego was (especially ignoring the N9 as not really Meego).

Enough people seem to like WebOS that there is certainly no reason why something should not come of it. It would be somewhat surprising though if it challenged Android or iOS in any serious way.

Trusting the hardware too much

hummassa — 2012-02-17T01:47:19+00:00

Why a market, and not the length or an end-pointer?

LTTng in the Ubuntu kernel

compudj — 2012-02-17T01:28:15+00:00

It is available for Ubuntu 11.10 through this PPA: see https://launchpad.net/~lttng/+archive/daily

XBMC 11 "Eden"

pabs — 2012-02-17T01:19:09+00:00

I looked at the packaging. The upstream code still has problems that he needs to strip out and also the script used for that introduces more problems.

Tracking users

pabs — 2012-02-17T01:18:13+00:00

That does not sound like the right way to go about things. Much better would be to report the bug in the graphics drivers so that it gets fixed.

Quotes of the week

jd — 2012-02-17T01:10:57+00:00

Since HP is doing nothing useful with the Polyserv code, it should open source that as well. At least we'd get to use a high quality network filesystem.

Trusting the hardware too much

corbet — 2012-02-17T00:29:09+00:00

I'm not the poster you're responding to, but I did also check out a report in my code. It thinks this function in drivers/media/video/ov7670.c is an infinite loop:

static int ov7670_write_array(struct v4l2_subdev *sd, struct regval_list *vals)
{
	while (vals->reg_num != 0xff || vals->value != 0xff) {
		int ret = ov7670_write(sd, vals->reg_num, vals->value);
		if (ret < 0)
			return ret;
		vals++;
	}
	return 0;
}

...but it's just reading through a static array, looking for the end marker.

Open webOS governance model described

pabs — 2012-02-17T00:15:41+00:00

I doubt the CPU design is open.

Open webOS governance model described

aleXXX — 2012-02-17T00:10:37+00:00

In the meantime, Mer is alive: http://makeplaylive.com/
A fully open source tablet, powered by KDE Plasma Active :-)

Alex

Intel's upcoming transactional memory feature

rise — 2012-02-17T00:06:07+00:00

I believe the paper you're referencing is the Hofmann, Rossbach, and Witchel[0] one? It's interesting, but from a quick read it appears all their results are from a machine simulator and describe a time of HTM that requires explicit conversion of parts of the kernel. I'm not at all sure it's directly comparable or evidence that Intel's model of HTM will provide "no benefit at all". They looked only at the kernel (already highly optimized around locking, disregarding other potential users), use a massively simplified in-order x86 model[1], and the handling of more complex & advanced effects in the far-from-ideal Intel hardware - say on instruction caches/prefetching, reordering, speculative execution, etc. - are outside the paper's focus. It's good research, but it's hardly conclusive evidence about real world performance of a somewhat different implementation on spectacularly different hardware.

[0] http://www.cs.utexas.edu/users/witchel/pubs/hofmann09aspl...
[1] "Because exercising an operating system imposes a heavy burden on
simulation time, we use Simics’ in-order processor model
at 1 cycle per instruction"

Wayland - Beyond X (The H)

khc — 2012-02-16T23:55:39+00:00

I use X network transparency and I am watching this thread, but haven't commented so, mostly because the discussion mostly doesn't involve people who actually work on wayland, and convincing people like you that the feature is useful seems pointless to me. I should also note that the number of people who claim that no one uses X network transparency isn't that high either, so 10 people in this sample is likely to be significant.

That said, I am not too worried. By the time X11 is phased out there will be an acceptable solution (however it's implemented), precisely because enough people find it useful.

Wayland - Beyond X (The H)

Cyberax — 2012-02-16T23:43:50+00:00

>Gallium3D has been used for what you describe (see article on Phoronix [1]), though that only helps if you have a Gallium3D driver on the other side

There's no need for Gallium3D driver on the host side. Indeed 3D guest acceleration in VMWare works fine with NVidia blob or even DirectX on Windows.

>I would have thought that directly proxying OpenGL ES might be a better idea (it has been specially developed for a small footprint as far as I can see), though Gallium3D might be useful for translating other APIs (like OpenGL + GLX) to OpenGL ES.

Direct proxying has some problems. It's way too expensive for one thing, try to run APITrace ( http://zrusin.blogspot.com/2011/04/apitrace.html ) and see it for yourself.

Trusting the hardware too much

marcH — 2012-02-16T23:43:24+00:00

Could you please post here a simplified version of the code falsely reported as an infinite loop + a link to the real code?

Garrett: Some things you may have heard about Secure Boot which aren't entirely true

RogerOdle — 2012-02-16T23:39:00+00:00

Only a threat to hobbyist Linux? Then it is a threat to everyone. Since when are only corporations considered legitimate competitors in the market? This as much as admits that the system is a barrier to market entry. It is most certainly anti-competitive as it is intended to make it harder to replace the Microsoft junk that is delivered with your hardware with something you actually want.

So everyone who decides to use a free-of cost Linux distro as their primary computer system is a Linux hobbyist? Then every home user of a Window computer is a Microsoft hobbyist and every home user of an apple product is a hobbyist. The use of Linux for casual use is increasing. It is every bit as legitimate and significant as any activity done with the proprietary products. An operating system is only a hobby if you spend your time actually tinkering with it. If you use it as your primary computer for communications and personal business then it is a tool that serves exactly the same purpose as Windows or OSX. It is no hobby.

Secure boot intends to take choice away from me. It will not make Windows any safer but only enable Microsoft to put less effort into making its product save and operating properly in the first place. Windows is unsafe by design and always will be. There is too much market history to make it otherwise. A safe Windows would be so inconvenient to use that it would be a complete failure in the market place. Secure boot doesn't fix that, it just protects the disease.

Quotes of the week

rahulsundaram — 2012-02-16T23:32:04+00:00

Are you of the incorrect impression that Fedora hasn't?

RSA keys not as random as they should be (The H)

Ben_P — 2012-02-16T23:23:51+00:00

That second link was great, thanks.

Wayland - Beyond X (The H)

rqosa — 2012-02-16T23:13:27+00:00

Windows XP might feel more responsive because it doesn't use compositing, which can have a performance cost (especially on older GPUs). On my 4.5-years-old hardware, programs feel slightly more responsive when KWin's compositing is turned off than when it's on.

(And of course there's also the possibility that the slowness you're experiencing is the fault of the applications and/or the widget toolkits, rather than the underlying window system. For example, I've noticed that Qt4 seems a lot slower than Qt3 when running on older CPUs.)

Wayland - Beyond X (The H)

rqosa — 2012-02-16T22:47:47+00:00

But those users already have an operating system they like (one that is already FLOSS, even). So how can there be there any good reason to change GNOME (and the underlying infrastructure it uses) to make it more like Android?

(And if your answer is something like "Android isn't really FLOSS", then the real solution to that is that we need to have unlocked hardware capable of running the community-developed Android rebuilds like CyanogenMod and Replicant on, and to educate the public about why locked-down hardware is bad.)

Wayland - Beyond X (The H)

dlang — 2012-02-16T22:45:31+00:00

two things.

1. having it be separate lets you position it better.

2. I was actually assuming that you would get a 'real' keyboard. In the past I've seen full-size M series type 'clicky' keyboards that have the erasermouse pointer in them.

by the way, I somewhat question if a thumb on a trackpad is really that much less accurate than the erasermouse joysticks, but I guess that's a personal preference :-)

Quotes of the week

ballombe — 2012-02-16T21:56:26+00:00

Fedora is supposed to be bleeding edge but Debian has moved to grub2 a long time ago.

Wayland - Beyond X (The H)

khim — 2012-02-16T21:53:50+00:00

the rest of the keyboard is much better

How come? Most of the look like this - basically laptop keyboard without a laptop. Not exactly sure how separation of keyboard from laptop can suddenly make it "much better".

Linux support for ARM big.LITTLE

dlang — 2012-02-16T21:45:23+00:00

I guess I'm saying that it doesn't seem as if the long-term scheduler changes are very significant, and as such I don't see a lot of value in producing such a short-term hack to deal with the issue.

especially as the long term fix is needed to deal with shipping Intel/AMD x86 systems

Linux support for ARM big.LITTLE

dlang — 2012-02-16T21:35:34+00:00

Ok, that may be a short-term hack, but such a hack should probably not go into the mainline scheduler.

My point is that we already have these 'problems' on mainstream systems.

On Intel and AMD x86 CPUs we already have cases where turning off some cores will let you run other cores at a higher clock speed (thermal/current limitations), and where you can run some cores at lower speeds than others

These may not be as big a variation as the ARM case has, but it's a matter of degree, not a matter of being a completely different kind of problem.

I agree that the current scheduler doesn't have explicit code to deal with this today, but I think that for the most part the existing code will 'just work' without modification. The rebalancing code pulls work off of a core if the core is too heavily loaded. a slower core will be more heavily loaded for the same work than a faster core would be, so work will naturally be pulled off of a heavily loaded slow core.

The two points where the current scheduler doesn't do the right thing are in the rebalancing code when considering moving processes between cores of different speeds (but only if you have CPU hog processes that will max out a core). As I note above, fixing this doesn't seem like that big a change, definitely less intrusive than the NUMA aware parts.

let userspace figure out all the nuances of what combinations of clock speeds on the different cores will work in the current environment (if it's limited by thermal factors, then different cooling, ambient temperatures, etc will change these limits, you really don't want that code in the kernel)

RSA keys not as random as they should be (The H)

tialaramex — 2012-02-16T21:33:37+00:00

Jake's apparent surprise that GnuPG is not affected reflects a general misunderstanding of what's going on here. This is an implementation bug. All the _facts_ reported in the paper are correct, but you should check other sources before believing their conclusions, let alone leaping to more general conclusions like "there's a chance my bank is affected".

Kaminsky explains that this isn't about RSA versus anything, unless in the sense that RSA beats everything because it was the only public key algorithm being used widely enough for this sort of result to be found:

http://dankaminsky.com/2012/02/14/ronwhit/

Heninger explains what causes this sort of phenomenon (bad implementations + poor entropy) and gives you some idea where all these vulnerable keys came from (think $50 Internet appliance, not $50Bn Internet bank)

https://freedom-to-tinker.com/blog/nadiah/new-research-th...

Tor offers SSL obfuscation for users behind censorship walls

jake — 2012-02-16T21:30:32+00:00

> ...so you're ... writing an article about it?

I think you might be overestimating our reach just a tad. But, beyond that, there's been a lot of press about it, including the executive director of the Tor project quoted in Forbes (noted further down in the article).

And, without any publicity, how would the request for additional bridges actually get out?

jake

RSA keys not as random as they should be (The H)

masoncl — 2012-02-16T21:25:50+00:00

Kudos for LWN for being the first place I've seen mention in big friendly letters the status of gpg keys.

Linux support for ARM big.LITTLE

jzbiciak — 2012-02-16T21:23:57+00:00

Keeping my abstraction straight, I should have said "Even if Linux were able to schedule for all 2*N CPUs." And carrying the thought further, I mean "schedule efficiently and appropriately for the CPU mix."

Wayland - Beyond X (The H)

dlang — 2012-02-16T21:23:50+00:00

> There are very few of them and they are no better then ThinkPad's built-in one, so what's the point?

the rest of the keyboard is much better

Tor offers SSL obfuscation for users behind censorship walls

robert_s — 2012-02-16T21:22:10+00:00

"the Tor project asked users to help restore connectivity for people in the region by setting up obfuscated bridges — but cautioned that drawing too much public attention to the project could prompt authorities to implement countermeasures."

...so you're ... writing an article about it?

Linux support for ARM big.LITTLE

jzbiciak — 2012-02-16T21:21:08+00:00

The last three paragraphs of the article really summarize why.

The current scheduler does not really understand heterogeneous CPU mixes. But, you can still do better than ARM's hypervisor-based switcher by pushing the logic into the kernel, and doing this pair-wise switcheroo. Then, the existing Linux infrastructure just models it as a frequency change within its existing governor framework.

Longer term, of course, you do want to teach Linux how to load balance properly between disparate cores, so at the limit, you could have all 2*N CPUs active on a machine with an N-CPU A15 cluster next to an N-CPU A7 cluster. But in the short run, pulling ARM's BSD-licensed switching logic to do the pair-wise switch at least gets something running that works better than leaving it to the hypervisor. The short run use model really does appear to be to have N CPUs powered on when you have an N CPU A15 cluster next to an N CPU A7 cluster.

Another thought occurs to me: Even if Linux were able to schedule for all 8 CPUs, the possibility exists that the environment around it doesn't really support that. It might not have the heat dissipation or current carrying capacity to have all 2*N CPUs active. So, that's another reason the pair-wise switch is interesting to consider.

Wayland - Beyond X (The H)

tstover — 2012-02-16T21:08:08+00:00

> This may be the key difference. I have 20/20 vision (rarity today, I know)

as do I. (up until a few years ago it was even better than that). For many the issue is very much leaning forward to get closer to the screen. One of the many reasons I recommend monitor arms for desktop systems.

Torso height is the other big factor. If you sit with proper posture without bending your neck and your eyes can look close to straight ahead - then great! Many people have to sharply look down to do this which is unnatural to say the least. This causes the had to bend down, which eventually caused the back to slouch.

If you are reading this and you find your self doing this, please take the chance to start new habits.

Wayland - Beyond X (The H)

cdmiller — 2012-02-16T21:02:06+00:00

This statement:

"and MacOS for the users who want actually usable *nix."

appears to fall under:

"And how we've entered realm of pure fantasy and self-delusion."