Re: [PATCH 08/24] net, diet: Make TCP metrics optional
From: josh
Date: Tue May 06 2014 - 13:55:57 EST
On Tue, May 06, 2014 at 01:16:43PM -0400, David Miller wrote:
> From: josh@xxxxxxxxxxxxxxxx
> Date: Tue, 6 May 2014 09:41:08 -0700
>
> > Every KB of RAM costs real money and SoC die area (for eDRAM/eSRAM).
>
> Another poster commented that 16MB of DRAM would be cheaper than
> the 2MB of ram you have on these boards, probably one that fits
> your size profile is available as well.
>
> 2MB is just a rediculous restriction.
Embedded systems experts disagree with you there; there *are* systems
where the most cost-efficient approach is a few MB (or a few hundred KB)
of non-discrete memory. We're not talking about socketed memory or even
soldered-down memory; we're talking about entire systems that fit on a
small SoC die. The space not used by that extra RAM may well be better
spent on CPU optimizations, or some other integrated component.
Such boards will be built, and many of them will run Linux, despite your
incredulity. When you're building millions of a board, it's well worth
optimizing software to eliminate components from the bill of materials.
And even on a system with 4MB or 8MB or 16MB of memory, a few hundred
extra KB used by the kernel and unavailable to userspace *matters*; that
could be the difference between fitting in 8MB or 16MB.
> And last time I checked Linux wasn't a special purpose operating
> system
No, it's an extremely general-purpose operating system, supporting
enough customization to run on everything from supercomputers to some
embedded systems. And that's partly because people who care about those
systems submit patches to make Linux scale. You take patches to scale
*up* to absurdly huge systems; what makes it so painful to take patches
to scale *down*?
> , but lucky for you I hear there are lots of those around.
Why would I want to run one of those when I can run Linux?
- Josh Triplett
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/