Networking on tiny machines

Posted May 27, 2014 22:09 UTC (Tue) by renox (guest, #23785)
In reply to: Networking on tiny machines by dlang
Parent article: Networking on tiny machines

> the huge changes the Android devs have been making aren't in the kernel, they are in userspace.

Uh? These changes are not relevant here, as the GP was talking about Linux.

> There have been a handful of features that they've added to the kernel, and after a lot of discussion those are getting integrated (or replaced with something the upstream devs and the android devs can agree on). So at best you are mixing issues.

Given the time and the difficulty for to have these 'handful of features' integrated into the mainline, I'd say that he is right..

Networking on tiny machines

Posted May 28, 2014 0:01 UTC (Wed) by dlang (guest, #313) [Link]

well, the OP talks about replacing functions instead of maintining patches against libraries.

what libraries does the kernel maintain?

It's far from obvious that this is talking about kernel functions.

Networking on tiny machines

Posted May 28, 2014 6:03 UTC (Wed) by smurf (subscriber, #17840) [Link] (4 responses)

There are a couple of reasons why wakelocks or the Binder haven't been accepted as they are, and those have nothing to do with mobile phones' small footprints, memory or otherwise.

Don't twist history.

Networking on tiny machines

Posted May 28, 2014 14:43 UTC (Wed) by raven667 (subscriber, #5198) [Link] (3 responses)

You are right that the reason these features were rejected as-is is not due to mobile devices small resources but it has a lot to do with the fact that the kernel has many many constituencies a large number of which are big iron and any new features have to be workable across the entire gamut of places where Linux is used, so features have to integrate well with the overall scheme, layout and style of the kernel, can't cause too many regressions on other completely unrelated systems and should be generally useful to those other systems as well which is why the specific code wasn't pulled in, as it was too much bolted on and single use, but the fact that these features were written provides an example of what is possible and what is needed so they were re-implemented in ways that had broader consensus across the Linux kernel ecosystem.

Networking on tiny machines

Posted May 29, 2014 7:43 UTC (Thu) by smurf (subscriber, #17840) [Link]

That being said, IMHO the demand for shrinking the kernel back down to something that works well on single-digit MByte machines is a reasonable goal.

It'll probably live in its own tree before getting into mainline, but then the linux-tiny patchset of earlier times did the same thing. So did/do the RT patches, for that matter.

Networking on tiny machines

Posted May 31, 2014 4:22 UTC (Sat) by garyamort (guest, #93419) [Link] (1 responses)

"any new features have to be workable across the entire gamut" - no they don't. In the case of things like various schedulers and power control management - as long as the userspace API is identical they don't need to work across all systems.

The i/o scheduler for example has many different patterns, some of which work better under different circumstances.

Multiple processor schedulers could be included in the kernel as well - rather then requiring constantly updated patch sets for every new kernel.

For an area I am familiar with, just browse through the ARM directories:
https://github.com/torvalds/linux/tree/master/arch/arm

Lots of kernel bits there for custom chips which are only found in specific hardware devices.

Also since there seems to be some confusion, I'm not saying a lot of kernel devs are hostile to mobile phones or whatnot - I'm saying that for the most part, their personally concerned with large, multiprocessor servers and high end hardware. If a new feature doesn't have some affect on what their interested in, it is quite often dismissed. Consider the comments quoted for this article.

Changes which would provide real benefits today but "don't further" some future goal, which historically can take years to be implemented, and which don't benefit the personal use cases of the maintainer - rejected.

Changes which provide performance benefits in real use cases by the submitter are rejected because the maintainer guesses that they won't apply to others - while at the same time admitting that he wouldn't use Linux for any of those use cases so he is not in a good position to judge.

Networking on tiny machines

Posted May 31, 2014 7:56 UTC (Sat) by dlang (guest, #313) [Link]

The question of schedulers has been discussed many times. This is one of those things that Linus has very strong feelings on.

He's seen other systems start to have vastly different schedulers for different purposes, and the end result is that there is a lot of confusion and each one is tailored for a specific use case, but that use case doesn't match what the users are actually needing to do (and/or users end up needing to do a little bit of multiple different types of work that each scheduler developer says "well, if you want to do that, don't use my scheduler")

and I'll say that the current disk schedulers seem to have this problem, although there is a little bit of a difference in that sometimes the disk controller does some of the work for the kernel, so there is more of a case for the noop scheduler, but there isn't the equivalent for the task scheduler)