LWN: Comments on "LFCS: ARM, control groups, and the next 20 years"

LFCS: ARM, control groups, and the next 20 years

rilder — Sat, 16 Apr 2011 20:39:23 +0000

I should have clarified better. I was not referring to any scheduler with complexity of O(1). I was specifically referring to scheduler predating current CFS in mainline. That scheduler was called O(1), and *no*, current BFS is not similar to that. One of most salient differences being, the history or any history distribution not being maintained by either BFS or CFS. FreeBSD, OTOH, still has a scheduler (ULE) with semantics predating back to that O(1) scheduler linux *had*. Check -- http://jeffr-tech.livejournal.com/24280.html -- for some interesting nitbits. Also, with regards to interactivity (which is what I was referring to earlier when i meant desktops), this scheduler is not up to the mark. There is also a proposal to "clean room" port BFS to FreeBSD among GSoC projects.

LFCS: ARM, control groups, and the next 20 years

oak — Sat, 16 Apr 2011 14:38:11 +0000

It's unlikely to replace his x86 workstation as x86 has the performance lead. ARM leads on power efficiency which is important for mobile & battery powered devices, but I don't think kernel devs are going to be doing their development (and builds) e.g. on their phones... :-)

LFCS: ARM, control groups, and the next 20 years

corbet — Sat, 16 Apr 2011 13:46:57 +0000

Umm... the current CFS scheduler was written (as was Con's deadline scheduler before it) to get all of those interactivity heuristics out of the kernel. They are still mostly gone. Con's BFS (which is not an O(1) scheduler sticks with the fairness approach. Things have improved since the O(1) days.

LFCS: ARM, control groups, and the next 20 years

WolfWings — Sat, 16 Apr 2011 10:07:14 +0000

[...] They still use a O(1) scheduler which Linux used eons back. [...]

And many of the largest users of Linux have forward-ported the O(1) scheduler *BACK* into Linux as of 2.6.26 at least, and some users are using the tree w/ the BrainFuck scheduler instead, which is another O(1) scheduler that works all the way up to 2.6.38 already.

http://lwn.net/Articles/357658/

http://ck.kolivas.org/patches/bfs/

So, just because the 'official' mainline Linux scheduler is no longer the 'old O(1) scheduler' doesn't mean that O(1) schedulers are dead, they're quite actively used, and many people prefer them to the recent attempts to add more brains to the scheduler. Much like trying to add filesystem-aware processing to hard drives, I don't think adding deeply program-aware tuning to schedulers without trusting the programs to tell the kernel about themselves will work, long-term.

LFCS: ARM, control groups, and the next 20 years

rilder — Fri, 15 Apr 2011 21:02:27 +0000

Comparison of FreeBSD of Linux is unfair in this context. You should in turn compare FreeBSD to distros which do a similar thing and they are doing a pretty good job there.

The 'numbers' that people point out wrt. FOSS needn't be just the core developers but it can also be testers, distro packagers, bug reporters, users. So more people scrutinizing the code will mean more eyes naturally. What FreeBSD lacks and Linux has is the concept of diverse distros from Gentoo,Exherbo to Ubuntu which will provide a whole spectrum of feedback to upstream developers. The feedback IMO is quite as important as other things.

People may be quick to point out the fragmentation this may have caused but a richer, diverse user/development base also contributes to richer products on long term, fittest stay and sustain (think of Genetic algorithms).

OTOH, FreeBSD which has been emphatically been pointed is *NOT* up to the mark in desktop, though they are quite good in servers. They still use a O(1) scheduler which Linux used eons back. A quick peek at their GSOc ideas page quickly reveals a stark difference between features in Linux and FreeBSD. I can point out specifics but don't want to since I love both and aware of their field of application.

"
A small, skilled team that has a focused set of real-world goals is going to accomplish much higher quality work than what a throng of "newbs" can pull off."
This is one of the mistakes made by many development teams -- a closed system model with a cathedral style development. Fortunately, "small team with real-world goals" often produce software which only they can use and end up using. Surprisingly smugness is also something which never fades in the community.

LFCS: ARM, control groups, and the next 20 years

p2mate — Fri, 15 Apr 2011 18:11:49 +0000

I would argue it's the other way around. There are only 3 companies who can make modern x86 cores: Intel, AMD and VIA. Intel doesn't license the necessary patents to others (besides those 2) to allow them to make x86 cores. Anyone with enough money can buy an ARM architecture license though which allows making your own core. At least the following companies have at some point made their own cores or modified the ones provided by ARM : Digital, Intel, Marvel, Qualcomm, Samsung and more companies are working on new cores.

LFCS: ARM, control groups, and the next 20 years

mrfredsmoothie — Fri, 15 Apr 2011 14:20:01 +0000

Are you taking donations? ;-)

LFCS: ARM, control groups, and the next 20 years

BenHutchings — Thu, 14 Apr 2011 23:28:12 +0000

It does work the way I said: the boot loader passes in a machine type number. But the kernel still has to have a built-in definiton of each machine type.

The current discussion is about having the boot loader pass in a fuller machine description (the Device Tree). This may simply be tacked onto the end of the kernel image in some way, so there is no need to modify existing boot loaders.

LFCS: ARM, control groups, and the next 20 years

dlang — Thu, 14 Apr 2011 18:54:37 +0000

actually, in the discussion on linux kernel it was proposed to make the bootloader pass this information to the kernel, and there was a large amount of opposition from many of the ARM people to this suggestion.

based on this I don't believe that it works that way today.

LFCS: ARM, control groups, and the next 20 years

cpeterso — Thu, 14 Apr 2011 16:20:23 +0000

Someone should give Linus shiny new ARM workstation. Then the ARM hassles will be _his_ hassles (and they will get fixed). ;)

LFCS: ARM, control groups, and the next 20 years

BenHutchings — Thu, 14 Apr 2011 13:24:24 +0000

ARM keeps tighter control of their architecture than Intel has ever been able to with x86. Very few commercial ARM cores have been designed outside of ARM. The problems are mostly outside the CPU, and they lie not so much in customisation (though there is much apparently pointless wheel-reinvention) but in lack of discoverability.

Most platforms have basic devices like an interrupt controller and interval timer that can just be assumed to be present. On x86 you get a PIC or APICs and a PIT or HPET. The newer versions even have backward-compatible modes. On ARM there are a wide variety of interrupt controllers and timers, and no reasonable way to probe for them. The boot loader is supposed to tell the kernel which type of machine it's booting on, and sometimes the system vendor even gets this right... but AFAIK the kernel isn't yet able to initialise the right set of drivers based solely on that.

LFCS: ARM, control groups, and the next 20 years

psankar — Thu, 14 Apr 2011 11:20:49 +0000

Is there a video recording of this session ?

LFCS: ARM, control groups, and the next 20 years

error27 — Thu, 14 Apr 2011 09:43:24 +0000

Newbs don't really hurt anything. They do small easy to review patches. The negative quality code goes in staging. It either improves or it gets dropped.

You do see people learn as well. You reject their patches and they start breaking them up properly and writing better changelogs. It sounds stupid but it makes a big difference.

LFCS: ARM, control groups, and the next 20 years

jthill — Thu, 14 Apr 2011 06:56:30 +0000

People's skills change over time, mostly with growing experience. Where will the next batch of good devs come from, and where will they go?

LFCS: ARM, control groups, and the next 20 years

james — Thu, 14 Apr 2011 06:06:50 +0000

Also, I understand that most of the x86 platform has discoverability built in, so various OSes (possibly user-installed) can work out what's in the system and how to use it. On most ARM systems, that's an unnecessary expense and power draw, since it can be hard-coded in the highly-constrained software environment.

LFCS: ARM, control groups, and the next 20 years

elanthis — Thu, 14 Apr 2011 02:52:22 +0000

It's not particularly surprising. What is surprising is how the quantity-over-quality approach is so often praised by the Linux users.

One or two fantastic developers are worth 20 mediocre developers, and each of those mediocre developers is worth 100 idiot developers. (And the really bad developers are basically just negative worth and cancel out the value of better developers on the same team.)

Linux -- and much FOSS -- is praised for a many-eyes, scratch-an-itch approach to development. Anyone with real experience with software development knows better. A small, skilled team that has a focused set of real-world goals is going to accomplish much higher quality work than what a throng of "newbs" can pull off. Linux has a lot of skilled devs, but so does FreeBSD, and the masses of amateur Linux contributors just don't amount to much in comparison.

LFCS: ARM, control groups, and the next 20 years

xxiao — Thu, 14 Apr 2011 02:26:13 +0000

maybe, it's time to switch linux's focus to ARM instead of x86 these days.

I hope Linus works at Linaro to achieve this shift. LF is basically an Intel shop, though I could be wrong.

LFCS: ARM, control groups, and the next 20 years

drdabbles — Wed, 13 Apr 2011 21:17:37 +0000

I suspect the important difference between the ARM arch and the x86 arch is that there are gobs of generic x86 systems out there with the same exact cpu in them, and with a roughly equivalent basic bill of materials.

In the arm space, there are loads of custom parts. Custom CPUs, custom boards, etc. Very little is the same across multiple devices, which makes it very difficult to have a generic platform to bless as your standard. In fact, there are still ARM chips in heavy use that have no MMU.

This can most easily be seen by building a defconfig for an x86 system and booting it and trying to build a defconfig for an ARM device.

LFCS: ARM, control groups, and the next 20 years

corbet — Wed, 13 Apr 2011 20:58:21 +0000

Over here. It was a QOTW last week.

LFCS: ARM, control groups, and the next 20 years

patrick_g — Wed, 13 Apr 2011 20:56:21 +0000

>>> Ingo Molnar recently pointed out that FreeBSD is getting Linux-like quality with a much smaller development community and suggested that it was because the user space and kernel are developed together.

Do you have a link to the post from Ingo ?

LFCS: ARM, control groups, and the next 20 years

mrfredsmoothie — Wed, 13 Apr 2011 19:04:59 +0000

The next guy who wants to ship a product w/ the same SOC (or peripherals).

LFCS: ARM, control groups, and the next 20 years

cpeterso — Wed, 13 Apr 2011 16:57:20 +0000

> There are 70 different sub-architectures and 500 different SoCs in the ARM tree.

Perhaps the cleanest and/or most popular ARM sub-architecture should be blessed as the primary platform code (like the x86 32/64-bit merge). If the other sub-architectures don't want to play, they can be developed out-of-tree. If a sub-architecture is only used by its developer, then who benefits from it being included in the Linus tree?