Re: [PATCH 08/24] net, diet: Make TCP metrics optional
On 05/07/2014 02:33 AM, Cong Wang wrote: On Tue, May 6, 2014 at 10:55 AM, wrote: On Tue, May 06, 2014 at 01:16:43PM -0400, David Miller wrote: From: j...@joshtriplett.org 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. So why bothers 3.15+ Linux kernel? Why not use an old kernel e.g. 2.4.x? 2.4.x kernel doesn't have so many new features you want to get rid of here. Maybe 2.4.x kernel doesn't have so many new features that we want to use here. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/24] net, diet: Make TCP metrics optional
On 05/07/2014 02:33 AM, Cong Wang wrote: On Tue, May 6, 2014 at 10:55 AM, j...@joshtriplett.org wrote: On Tue, May 06, 2014 at 01:16:43PM -0400, David Miller wrote: From: j...@joshtriplett.org 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. So why bothers 3.15+ Linux kernel? Why not use an old kernel e.g. 2.4.x? 2.4.x kernel doesn't have so many new features you want to get rid of here. Maybe 2.4.x kernel doesn't have so many new features that we want to use here. -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/24] net, diet: Make TCP metrics optional
On Tue 2014-05-06 11:33:11, Cong Wang wrote: > On Tue, May 6, 2014 at 10:55 AM, wrote: > > On Tue, May 06, 2014 at 01:16:43PM -0400, David Miller wrote: > >> From: j...@joshtriplett.org > >> 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. > > So why bothers 3.15+ Linux kernel? Why not use an old kernel e.g. 2.4.x? > 2.4.x kernel doesn't have so many new features you want to get rid of here. So.. what is kernel composed of? Ton of drivers and a bit of generic code. And when doing this, you probably need the drivers from 3.x for your hardware. -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/24] net, diet: Make TCP metrics optional
On Tue 2014-05-06 11:33:11, Cong Wang wrote: On Tue, May 6, 2014 at 10:55 AM, j...@joshtriplett.org wrote: On Tue, May 06, 2014 at 01:16:43PM -0400, David Miller wrote: From: j...@joshtriplett.org 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. So why bothers 3.15+ Linux kernel? Why not use an old kernel e.g. 2.4.x? 2.4.x kernel doesn't have so many new features you want to get rid of here. So.. what is kernel composed of? Ton of drivers and a bit of generic code. And when doing this, you probably need the drivers from 3.x for your hardware. -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/24] net, diet: Make TCP metrics optional
On 2014-05-07 15:35, One Thousand Gnomes wrote: > IoT devices don't care. Most embedded devices don't care. A lot of the > current generation of proprietary non Linux very low end RTOS systems > support *one socket*, some even use a wireless controller which has a > proprietary mini tcp/ip and wifi stack that provices *one socket* > > If you want Linux to run on the kind of low end 'single chip' systems or > FPGA systems then you want to be able to run in very little memory. > Network performance is usually near irrelevant. If its controlling a > smart plug it doesn't need to do megabit encrypted streams or fast > connect. > This describes an industrial control system I've been working on for the last ten years or so. It runs one application, this application makes one single TCP connection to a server which then stays up forever. The server can send modified configuration to the application and the application sends periodic reports about what it is doing. We've replaced 9600 bps current loop with TCP, not for performance reasons but for convenience. We have no use for ethtool, no use for packet filters, no use for firewalling and don't care if a socket uses 100 bytes or 10kBytes of kernel memory since we only have one. There are probably lots of embedded systems that need those features, but there are also lots of systems that don't. The first version of the hardware used a 2.4.26 kernel on an Axis ETRAX LX processor, now were using a 2.6.33 kernel on an Atmel ARM9 processor. We have a problem with the flash getting corrupted every now and then, and this seems to be fixed in the latest stable kernel (3.10). There are about 2000 changes to drivers/mtd and so far we have not been able to bisect this to find out where and why things started working. So we'd like to upgrade but we are also starting to run short on flash and the 3.10 kernel is noticeably bigger with the same configuration. Switching from gzip to xz compression did give us back enough flash space to fit everything in, but it's still tight. So if we can save a couple of 100k of text size and get a slightly less performant or featureful TCP stack, that would be a very good tradeoff for us. /Christer -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/24] net, diet: Make TCP metrics optional
On 2014-05-07 15:35, One Thousand Gnomes wrote: IoT devices don't care. Most embedded devices don't care. A lot of the current generation of proprietary non Linux very low end RTOS systems support *one socket*, some even use a wireless controller which has a proprietary mini tcp/ip and wifi stack that provices *one socket* If you want Linux to run on the kind of low end 'single chip' systems or FPGA systems then you want to be able to run in very little memory. Network performance is usually near irrelevant. If its controlling a smart plug it doesn't need to do megabit encrypted streams or fast connect. This describes an industrial control system I've been working on for the last ten years or so. It runs one application, this application makes one single TCP connection to a server which then stays up forever. The server can send modified configuration to the application and the application sends periodic reports about what it is doing. We've replaced 9600 bps current loop with TCP, not for performance reasons but for convenience. We have no use for ethtool, no use for packet filters, no use for firewalling and don't care if a socket uses 100 bytes or 10kBytes of kernel memory since we only have one. There are probably lots of embedded systems that need those features, but there are also lots of systems that don't. The first version of the hardware used a 2.4.26 kernel on an Axis ETRAX LX processor, now were using a 2.6.33 kernel on an Atmel ARM9 processor. We have a problem with the flash getting corrupted every now and then, and this seems to be fixed in the latest stable kernel (3.10). There are about 2000 changes to drivers/mtd and so far we have not been able to bisect this to find out where and why things started working. So we'd like to upgrade but we are also starting to run short on flash and the 3.10 kernel is noticeably bigger with the same configuration. Switching from gzip to xz compression did give us back enough flash space to fit everything in, but it's still tight. So if we can save a couple of 100k of text size and get a slightly less performant or featureful TCP stack, that would be a very good tradeoff for us. /Christer -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/24] net, diet: Make TCP metrics optional
On Tue 2014-05-06 11:59:41, David Miller wrote: > From: j...@joshtriplett.org > Date: Tue, 6 May 2014 08:57:03 -0700 > > > On Mon, May 05, 2014 at 11:23:27PM -0400, David Miller wrote: > >> From: Andi Kleen > >> Date: Tue, 6 May 2014 05:21:14 +0200 > >> > >> > What parts would you remove to get the foot print down for a 2MB > >> > single purpose machine? > >> > >> I wouldn't use Linux, end of story. > >> > >> Maybe two decades ago, but not now, those days are over. > > > > That's a self-fulfilling prophecy: > > Making 2MB RAM machines today makes no sense at all. > > The lowest end dirt cheap smartphone, something which fits on > someone's pocket, has gigabytes of ram. Low end smartphone is quite high-end device :-). It only has to run for few days on big battery. I have programmable watch with <64K RAM. Yes, that one runs for months on battery. > The only entity looking backwards are the people making these > improperly provisioned systems. There's nothing improper about small ammount of RAM to save power. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/24] net, diet: Make TCP metrics optional
On Mon 2014-05-05 23:12:29, David Miller wrote: > From: Andi Kleen > Date: Mon, 5 May 2014 15:25:57 -0700 > > > This is all the code that saves connection information > > between different sockets. Not really essential for > > small systems. > > It is absolutely essential unless you want poor performance > of TCP connections. Sounds like "poor" performance of TCP and 400KB memory free is tradeoff that makes for small machines. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/24] net, diet: Make TCP metrics optional
On Mon 2014-05-05 23:12:29, David Miller wrote: From: Andi Kleen a...@firstfloor.org Date: Mon, 5 May 2014 15:25:57 -0700 This is all the code that saves connection information between different sockets. Not really essential for small systems. It is absolutely essential unless you want poor performance of TCP connections. Sounds like poor performance of TCP and 400KB memory free is tradeoff that makes for small machines. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/24] net, diet: Make TCP metrics optional
On Tue 2014-05-06 11:59:41, David Miller wrote: From: j...@joshtriplett.org Date: Tue, 6 May 2014 08:57:03 -0700 On Mon, May 05, 2014 at 11:23:27PM -0400, David Miller wrote: From: Andi Kleen a...@firstfloor.org Date: Tue, 6 May 2014 05:21:14 +0200 What parts would you remove to get the foot print down for a 2MB single purpose machine? I wouldn't use Linux, end of story. Maybe two decades ago, but not now, those days are over. That's a self-fulfilling prophecy: Making 2MB RAM machines today makes no sense at all. The lowest end dirt cheap smartphone, something which fits on someone's pocket, has gigabytes of ram. Low end smartphone is quite high-end device :-). It only has to run for few days on big battery. I have programmable watch with 64K RAM. Yes, that one runs for months on battery. The only entity looking backwards are the people making these improperly provisioned systems. There's nothing improper about small ammount of RAM to save power. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/24] net, diet: Make TCP metrics optional
From: Tim Bird Date: Wed, 7 May 2014 15:19:03 -0700 > If you don't want to help avoid problems, I understand. All the kernel > maintainers are extremely busy. But the use cases are pretty interesting, > and it would be nice to have you on board. Or running with improper privileges. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/24] net, diet: Make TCP metrics optional
On Wed, May 7, 2014 at 10:20 AM, David Miller wrote: > From: One Thousand Gnomes > Date: Wed, 7 May 2014 14:59:38 +0100 > >> 16MB of DRAM means adding a chip to your system. You've just exceeded the >> space, power and cost budget on the very low end. In many cases like FPGA >> systems you can't even add DRAM without major hoop jumping. > > A year or so for now this may not be true, which makes these kinds of changes > very nearly in the "point in time solution" category. > > My main point in all of this is that whilst Linux should work on a braod range > of system types, there has to be a limit somewhere and I think 2MB is off > the deep end. > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ Linux 2.6.33 is currently running on a microcontroller with 2MB of flash and 256K of RAM. See Vitaly Wool's presentation from ELC about this here: http://elinux.org/images/c/ca/Spreading.pdf. It might be off the deep end, but I think that's pretty exciting. That's not a super-recent kernel, but I think current kernels could get to 512K RAM and 2MB flash with some elbow grease. That hits the sweet spot for where the deep embedded processors (everything on-die, at really aggressive price per unit) are heading in the next few years. I sympathize with the arguments about increasing configuration complexity, and the possibility of introducing bugs. "big switches" and LTO should both help with the config complexity problem. With regard to bugs, I think some of the patches may be a problem, and that's where the help of the networking experts would be great in helping to avoid problems. Dropping optional features is going to happen on these devices whether it's Linux running there or some RTOS. Linux will certainly be talking to these devices, if not running in them. So your life on the host side might be improved if you have some say what the stack looks like on the device side. If you don't want to help avoid problems, I understand. All the kernel maintainers are extremely busy. But the use cases are pretty interesting, and it would be nice to have you on board. -- Tim Bird -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/24] net, diet: Make TCP metrics optional
From: One Thousand Gnomes Date: Wed, 7 May 2014 14:59:38 +0100 > 16MB of DRAM means adding a chip to your system. You've just exceeded the > space, power and cost budget on the very low end. In many cases like FPGA > systems you can't even add DRAM without major hoop jumping. A year or so for now this may not be true, which makes these kinds of changes very nearly in the "point in time solution" category. My main point in all of this is that whilst Linux should work on a braod range of system types, there has to be a limit somewhere and I think 2MB is off the deep end. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/24] net, diet: Make TCP metrics optional
> But why go to all that trouble when there's a perfectly good networking > stack in the kernel? Even if most of these options aren't things that > would be useful to most systems, being able to turn them off and save > 1/3 of the kernel text size for tiny systems like this does makes a big > difference... There are a vast number of low memory devices for various platforms and FPGA devices. I've also been looking at this for some other projects and there is a reason I went back and started playing with 2.11BSD. > So why bothers 3.15+ Linux kernel? Why not use an old kernel e.g. 2.4.x? > 2.4.x kernel doesn't have so many new features you want to get rid of here. Simple answer. 2.11BSD is vastly superior on a small system to 2.4.x Linux. Also 2.4 is old and lightly maintained. Even forking 3.15 into bloatix and embedded Linux (ELKS2 ;-)) would make more sense. 2/11BSD has the advantage that you don't need virtual memory and you don't have the cost of page tables which are mostly useless on a device that small these days because I/O speeds are so much higher. It has a bloatfree userspace, although it does need chunks of the openbsd security work backporting. Forking a current Linux would give you all the modern stuff wanted like USB, SPI, eMMC etc but comes with all the debloating work and some annoying assumptions about memory. Do the fork off GregKH's next long term kernel and it wouldn't be that horrific to maintain until there is a clear picture about uses and whether it justifies merging ? > 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. 16MB of DRAM means adding a chip to your system. You've just exceeded the space, power and cost budget on the very low end. In many cases like FPGA systems you can't even add DRAM without major hoop jumping. On the Linux side there's also a ton of other stuff with vm handling that could be done far better for a small x86 device if the kernel was split (for now anyway). If it gets a lot of users then DaveM's arguments about unjustified maintenance hassle go away and it an then get re-merged. > 2MB is just a rediculous restriction. Linux used to run fine in 2MB ;-) > And last time I checked Linux wasn't a special purpose operating > system, but lucky for you I hear there are lots of those around. Server, desktop, tablet and even phone main OS devices are "special purpose" in the big picture of processor use. Even today 2MB is "big computer" to an awful lot of people! Alan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/24] net, diet: Make TCP metrics optional
On Tue, 06 May 2014 13:17:58 -0700 Eric Dumazet wrote: > On Tue, 2014-05-06 at 11:32 -0700, Andi Kleen wrote: > > > We simply can not compete with user space, as a programmer is free to > > > keep what he really wants/needs. > > > > Not true. > > You can shake the kernel as much as you want, you wont make : > - a TCP socket > - a dentry > - an inode > - a file structure > - eventpoll structures (assuming epoll use) > - 2 dst per flow. > > In 1024 bytes of memory, and keep an efficient kernel to handle > arbitrary number of sockets using the venerable and slow BSD socket api. IoT devices don't care. Most embedded devices don't care. A lot of the current generation of proprietary non Linux very low end RTOS systems support *one socket*, some even use a wireless controller which has a proprietary mini tcp/ip and wifi stack that provices *one socket* If you want Linux to run on the kind of low end 'single chip' systems or FPGA systems then you want to be able to run in very little memory. Network performance is usually near irrelevant. If its controlling a smart plug it doesn't need to do megabit encrypted streams or fast connect. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 08/24] net, diet: Make TCP metrics optional
From: j...@joshtriplett.org ... > Every KB of RAM costs real money and SoC die area (for eDRAM/eSRAM). > Look at how much cache low-end processors have, and imagine running > entirely out of *that*. Let's not surrender that entire class of > devices to VxWorks, FreeRTOS, and other painfully non-Linux systems, > when we already know it's possible to run Linux on them successfully. Have you considered running (say) NetBSD instead of Linux? You'll get more support there for running on 'small memory' systems. You can also make your own changes with having issues with the GPL. David -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 08/24] net, diet: Make TCP metrics optional
From: j...@joshtriplett.org ... Every KB of RAM costs real money and SoC die area (for eDRAM/eSRAM). Look at how much cache low-end processors have, and imagine running entirely out of *that*. Let's not surrender that entire class of devices to VxWorks, FreeRTOS, and other painfully non-Linux systems, when we already know it's possible to run Linux on them successfully. Have you considered running (say) NetBSD instead of Linux? You'll get more support there for running on 'small memory' systems. You can also make your own changes with having issues with the GPL. David -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/24] net, diet: Make TCP metrics optional
On Tue, 06 May 2014 13:17:58 -0700 Eric Dumazet eric.duma...@gmail.com wrote: On Tue, 2014-05-06 at 11:32 -0700, Andi Kleen wrote: We simply can not compete with user space, as a programmer is free to keep what he really wants/needs. Not true. You can shake the kernel as much as you want, you wont make : - a TCP socket - a dentry - an inode - a file structure - eventpoll structures (assuming epoll use) - 2 dst per flow. In 1024 bytes of memory, and keep an efficient kernel to handle arbitrary number of sockets using the venerable and slow BSD socket api. IoT devices don't care. Most embedded devices don't care. A lot of the current generation of proprietary non Linux very low end RTOS systems support *one socket*, some even use a wireless controller which has a proprietary mini tcp/ip and wifi stack that provices *one socket* If you want Linux to run on the kind of low end 'single chip' systems or FPGA systems then you want to be able to run in very little memory. Network performance is usually near irrelevant. If its controlling a smart plug it doesn't need to do megabit encrypted streams or fast connect. Alan -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/24] net, diet: Make TCP metrics optional
But why go to all that trouble when there's a perfectly good networking stack in the kernel? Even if most of these options aren't things that would be useful to most systems, being able to turn them off and save 1/3 of the kernel text size for tiny systems like this does makes a big difference... There are a vast number of low memory devices for various platforms and FPGA devices. I've also been looking at this for some other projects and there is a reason I went back and started playing with 2.11BSD. So why bothers 3.15+ Linux kernel? Why not use an old kernel e.g. 2.4.x? 2.4.x kernel doesn't have so many new features you want to get rid of here. Simple answer. 2.11BSD is vastly superior on a small system to 2.4.x Linux. Also 2.4 is old and lightly maintained. Even forking 3.15 into bloatix and embedded Linux (ELKS2 ;-)) would make more sense. 2/11BSD has the advantage that you don't need virtual memory and you don't have the cost of page tables which are mostly useless on a device that small these days because I/O speeds are so much higher. It has a bloatfree userspace, although it does need chunks of the openbsd security work backporting. Forking a current Linux would give you all the modern stuff wanted like USB, SPI, eMMC etc but comes with all the debloating work and some annoying assumptions about memory. Do the fork off GregKH's next long term kernel and it wouldn't be that horrific to maintain until there is a clear picture about uses and whether it justifies merging ? 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. 16MB of DRAM means adding a chip to your system. You've just exceeded the space, power and cost budget on the very low end. In many cases like FPGA systems you can't even add DRAM without major hoop jumping. On the Linux side there's also a ton of other stuff with vm handling that could be done far better for a small x86 device if the kernel was split (for now anyway). If it gets a lot of users then DaveM's arguments about unjustified maintenance hassle go away and it an then get re-merged. 2MB is just a rediculous restriction. Linux used to run fine in 2MB ;-) And last time I checked Linux wasn't a special purpose operating system, but lucky for you I hear there are lots of those around. Server, desktop, tablet and even phone main OS devices are special purpose in the big picture of processor use. Even today 2MB is big computer to an awful lot of people! Alan -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/24] net, diet: Make TCP metrics optional
From: One Thousand Gnomes gno...@lxorguk.ukuu.org.uk Date: Wed, 7 May 2014 14:59:38 +0100 16MB of DRAM means adding a chip to your system. You've just exceeded the space, power and cost budget on the very low end. In many cases like FPGA systems you can't even add DRAM without major hoop jumping. A year or so for now this may not be true, which makes these kinds of changes very nearly in the point in time solution category. My main point in all of this is that whilst Linux should work on a braod range of system types, there has to be a limit somewhere and I think 2MB is off the deep end. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/24] net, diet: Make TCP metrics optional
On Wed, May 7, 2014 at 10:20 AM, David Miller da...@davemloft.net wrote: From: One Thousand Gnomes gno...@lxorguk.ukuu.org.uk Date: Wed, 7 May 2014 14:59:38 +0100 16MB of DRAM means adding a chip to your system. You've just exceeded the space, power and cost budget on the very low end. In many cases like FPGA systems you can't even add DRAM without major hoop jumping. A year or so for now this may not be true, which makes these kinds of changes very nearly in the point in time solution category. My main point in all of this is that whilst Linux should work on a braod range of system types, there has to be a limit somewhere and I think 2MB is off the deep end. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ Linux 2.6.33 is currently running on a microcontroller with 2MB of flash and 256K of RAM. See Vitaly Wool's presentation from ELC about this here: http://elinux.org/images/c/ca/Spreading.pdf. It might be off the deep end, but I think that's pretty exciting. That's not a super-recent kernel, but I think current kernels could get to 512K RAM and 2MB flash with some elbow grease. That hits the sweet spot for where the deep embedded processors (everything on-die, at really aggressive price per unit) are heading in the next few years. I sympathize with the arguments about increasing configuration complexity, and the possibility of introducing bugs. big switches and LTO should both help with the config complexity problem. With regard to bugs, I think some of the patches may be a problem, and that's where the help of the networking experts would be great in helping to avoid problems. Dropping optional features is going to happen on these devices whether it's Linux running there or some RTOS. Linux will certainly be talking to these devices, if not running in them. So your life on the host side might be improved if you have some say what the stack looks like on the device side. If you don't want to help avoid problems, I understand. All the kernel maintainers are extremely busy. But the use cases are pretty interesting, and it would be nice to have you on board. -- Tim Bird -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/24] net, diet: Make TCP metrics optional
From: Tim Bird tbird...@gmail.com Date: Wed, 7 May 2014 15:19:03 -0700 If you don't want to help avoid problems, I understand. All the kernel maintainers are extremely busy. But the use cases are pretty interesting, and it would be nice to have you on board. Or running with improper privileges. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/24] net, diet: Make TCP metrics optional
On Tue, May 06, 2014 at 04:29:39PM -0700, Eric Dumazet wrote: > On Tue, 2014-05-06 at 14:05 -0700, Andi Kleen wrote: > > > - Make GRO optional. > > This is purely a performance feature for high bandwidth. > > Make this properly then, instead of relying on LTO. > > We did preliminary work to put this stuff in separate files, but its not > complete yet. FWIW doesn't matter for LTO. > > tcpv4_offload has pointers to tcp4_gro_receive() and tcp4_gro_complete() > > Is LTO smart enough to understand this will never be called, and do > proper code elimination of whole _gro_ helpers ? When there are pointers in static objects it cannot eliminate it for C (it may work for C++) However if you just remove the pointer it'll remove the rest. -Andi -- a...@linux.intel.com -- Speaking for myself only. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/24] net, diet: Make TCP metrics optional
On Tue, 2014-05-06 at 14:05 -0700, Andi Kleen wrote: > - Make GRO optional. > This is purely a performance feature for high bandwidth. Make this properly then, instead of relying on LTO. We did preliminary work to put this stuff in separate files, but its not complete yet. tcpv4_offload has pointers to tcp4_gro_receive() and tcp4_gro_complete() Is LTO smart enough to understand this will never be called, and do proper code elimination of whole _gro_ helpers ? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/24] net, diet: Make TCP metrics optional
On Tue, 2014-05-06 at 15:50 -0700, j...@joshtriplett.org wrote: > There's something very wrong if 2.4.x works for > cases that 3.x doesn't; that would be a serious regression. You'll have to ask Linus to bring back i386 support then, I believe it was removed in 3.8 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/24] net, diet: Make TCP metrics optional
On Tue, May 06, 2014 at 05:11:17PM -0400, David Miller wrote: > From: j...@joshtriplett.org > Date: Tue, 6 May 2014 14:08:15 -0700 > > > On Tue, May 06, 2014 at 04:44:10PM -0400, David Miller wrote: > >> From: Cong Wang > >> Date: Tue, 6 May 2014 11:33:11 -0700 > >> > >> > So why bothers 3.15+ Linux kernel? Why not use an old kernel e.g. 2.4.x? > >> > 2.4.x kernel doesn't have so many new features you want to get rid of > >> > here. > >> > >> +1 > > > > You've got to be kidding. Using 2.4 for a new network-connected device, > > today? With all of its potential security holes that nobody is paying > > attention to? Easier to fork 3.15 and trim it down than to do *that*. > > And there *are* a huge number of useful features in 3.15+, not least of > > which drivers for current hardware. > > So you're saying that the 2.4.x -stable maintainer did a shitty job and > his work is worthless? There's a difference between maintaining 2.4.x for all the existing users who can't or won't upgrade, and introducing a *new* product shipping with 2.4.x. There's something very wrong if 2.4.x works for cases that 3.x doesn't; that would be a serious regression. - Josh Triplett -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/24] net, diet: Make TCP metrics optional
From: j...@joshtriplett.org Date: Tue, 6 May 2014 14:08:15 -0700 > On Tue, May 06, 2014 at 04:44:10PM -0400, David Miller wrote: >> From: Cong Wang >> Date: Tue, 6 May 2014 11:33:11 -0700 >> >> > So why bothers 3.15+ Linux kernel? Why not use an old kernel e.g. 2.4.x? >> > 2.4.x kernel doesn't have so many new features you want to get rid of here. >> >> +1 > > You've got to be kidding. Using 2.4 for a new network-connected device, > today? With all of its potential security holes that nobody is paying > attention to? Easier to fork 3.15 and trim it down than to do *that*. > And there *are* a huge number of useful features in 3.15+, not least of > which drivers for current hardware. So you're saying that the 2.4.x -stable maintainer did a shitty job and his work is worthless? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/24] net, diet: Make TCP metrics optional
On Tue, May 06, 2014 at 04:44:10PM -0400, David Miller wrote: > From: Cong Wang > Date: Tue, 6 May 2014 11:33:11 -0700 > > > So why bothers 3.15+ Linux kernel? Why not use an old kernel e.g. 2.4.x? > > 2.4.x kernel doesn't have so many new features you want to get rid of here. > > +1 You've got to be kidding. Using 2.4 for a new network-connected device, today? With all of its potential security holes that nobody is paying attention to? Easier to fork 3.15 and trim it down than to do *that*. And there *are* a huge number of useful features in 3.15+, not least of which drivers for current hardware. - Josh Triplett -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/24] net, diet: Make TCP metrics optional
On Tue, May 06, 2014 at 10:07:38PM +0200, Richard Cochran wrote: > On Tue, May 06, 2014 at 12:50:49PM -0700, Andi Kleen wrote: > > > > > So I think Dave is right > > > in rejecting anything that compromises the _quality_ of the stack. > > > > I don't think anything I removed compromised quality (modulo bugs) > > It's still a more-features-than-your-typical-BSD TCP/IP stack > > But Dave seems to think so. Appeal to authority? The vast majority of the patches only remove optional user interfaces. If the single program running on the embedded system does not use these interfaces it's simply dead code. The patches that change non interface parts: - Make FASTOPEN optional. FASTOPEN is a very expensive feature because it pulls in the complete crypto subsystem. It's also a feature that needs to be explicitely enabled by the user program, and I doubt is widely deployed (my work station did exactly zero fast opens ever) - Make TCP_METRICS optional, so connections don't share state. - Simplify the routing table for the client < 10 routes case. Works exactly the same as before with a small number of routes. - Make GRO optional. This is purely a performance feature for high bandwidth. -Andi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/24] net, diet: Make TCP metrics optional
From: Eric Dumazet Date: Tue, 06 May 2014 13:17:58 -0700 > Adding ~1000 lines of code to save few KB was the point I gave up. +1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/24] net, diet: Make TCP metrics optional
From: Andi Kleen Date: Tue, 6 May 2014 22:06:44 +0200 >> You see, that's the point I'm trying to make, once it's upstream >> then it's my problem. > > FWIW I don't think any of the changes I proposed would be likely > to add lots of new bugs. Then you're living in a dream world, one in which the rest of us do not live in. Every new configuration combination is a new situation that competes testing wise with the others. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/24] net, diet: Make TCP metrics optional
From: Andi Kleen Date: Tue, 6 May 2014 12:50:49 -0700 > It's still a more-features-than-your-typical-BSD TCP/IP stack Said the guy posting patches to remove TCP metrics. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/24] net, diet: Make TCP metrics optional
> And if you're asking for someone to help pay attention to bug reports so > you don't have to, that's reasonable as well; just like you probably > have a stock response for "that's a crazy distro kernel, ask them about > it and not me", you could have a stock response for "that kernel has the > crazy embedded option turned on, ask the embedded people about it and > not me". It doesn't just have to be *your* problem alone. We could add a tainted flag for these configurations and a message at bootup to make it obvious in bug reports. Would that help? -Andi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/24] net, diet: Make TCP metrics optional
From: Cong Wang Date: Tue, 6 May 2014 11:33:11 -0700 > So why bothers 3.15+ Linux kernel? Why not use an old kernel e.g. 2.4.x? > 2.4.x kernel doesn't have so many new features you want to get rid of here. +1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/24] net, diet: Make TCP metrics optional
> In 1024 bytes of memory, and keep an efficient kernel to handle > arbitrary number of sockets using the venerable and slow BSD socket api. I agree running in 1024 bytes would be challenging. > Adding ~1000 lines of code to save few KB was the point I gave up. You're refering to fib_list? It currently has some duplicated code (this could/should be fixed). Or we could drop it, I suppose, if really everyone hates it. (I thought it was a cute idea, but I'm biased :-) Total it is saving 350k, about 30% of the total text size of the mini kernel (plus some dynamic savings) with networking. I would be happy to fix any reasonable objection. But fundamental "I don't care about anything smaller than my smart phone" type arguments are not particularly constructive. -Andi -- a...@linux.intel.com -- Speaking for myself only -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/24] net, diet: Make TCP metrics optional
On Tue, May 06, 2014 at 01:17:58PM -0700, Eric Dumazet wrote: > On Tue, 2014-05-06 at 11:32 -0700, Andi Kleen wrote: > > > We simply can not compete with user space, as a programmer is free to > > > keep what he really wants/needs. > > > > Not true. > > You can shake the kernel as much as you want, you wont make : > - a TCP socket > - a dentry > - an inode > - a file structure > - eventpoll structures (assuming epoll use) > - 2 dst per flow. > > In 1024 bytes of memory, and keep an efficient kernel to handle > arbitrary number of sockets using the venerable and slow BSD socket api. > > I was objecting to the "crazy things like LWIP" comment from Josh, not > to your patches in general. My primary statement was that it's crazy to use something like LWIP just because you want a *tiny* system. We could argue about using LWIP because you want a massively scalable system, or one that more closely couples userspace and the kernel, but that's not the current goal in any case. So let's drop that branch of the thread. :) > I actually took a look at them but stopped at patch 22 > > Adding ~1000 lines of code to save few KB was the point I gave up. Please consider ignoring that one and reading the rest; we could always handle the routing table issue separately. - Josh Triplett -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/24] net, diet: Make TCP metrics optional
On Tue, 2014-05-06 at 11:32 -0700, Andi Kleen wrote: > > We simply can not compete with user space, as a programmer is free to > > keep what he really wants/needs. > > Not true. You can shake the kernel as much as you want, you wont make : - a TCP socket - a dentry - an inode - a file structure - eventpoll structures (assuming epoll use) - 2 dst per flow. In 1024 bytes of memory, and keep an efficient kernel to handle arbitrary number of sockets using the venerable and slow BSD socket api. I was objecting to the "crazy things like LWIP" comment from Josh, not to your patches in general. I actually took a look at them but stopped at patch 22 Adding ~1000 lines of code to save few KB was the point I gave up. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/24] net, diet: Make TCP metrics optional
On Tue, May 06, 2014 at 01:25:01PM -0400, David Miller wrote: > From: j...@joshtriplett.org > Date: Tue, 6 May 2014 10:21:06 -0700 > > > On Tue, May 06, 2014 at 01:17:52PM -0400, David Miller wrote: > >> From: j...@joshtriplett.org > >> Date: Tue, 6 May 2014 09:45:46 -0700 > >> > >> > The kernel can do the same. Consider the idea of analyzing a set of > >> > userspace programs, determining what kernel functionality they do and > >> > don't need, feeding that information into the kernel build process, and > >> > automatically dropping unused bits of the kernel. > >> > >> Please make sure I'm not on the list of people who see reports for > >> bugs reported in that setup. > >> > >> Thanks :-) > > > > Fine by me. Just please allow such a setup to exist. :) > > You see, that's the point I'm trying to make, once it's upstream > then it's my problem. > > You absolutely must consider the burdon you put upon upstream > maintainers when you ask for things to be included. Absolutely. And Andi and I are both interested in working *with* you to find a way to run on tiny embedded systems *without* necessarily introducing excessive proliferation of configuration options or unnecessarily increasing your support burden. For instance, it's easy enough to key some options off of CONFIG_NR_CPUS (such as data structure sizes), or introduce a big config switch (CONFIG_NETWORK_FULL=n or similar) that controls all of these cases rather than having option for each. That would not be hard to supply in a v2 of this patch series. And if you're asking for someone to help pay attention to bug reports so you don't have to, that's reasonable as well; just like you probably have a stock response for "that's a crazy distro kernel, ask them about it and not me", you could have a stock response for "that kernel has the crazy embedded option turned on, ask the embedded people about it and not me". It doesn't just have to be *your* problem alone. 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/24] net, diet: Make TCP metrics optional
On Tue, May 06, 2014 at 12:50:49PM -0700, Andi Kleen wrote: > > > So I think Dave is right > > in rejecting anything that compromises the _quality_ of the stack. > > I don't think anything I removed compromised quality (modulo bugs) > It's still a more-features-than-your-typical-BSD TCP/IP stack But Dave seems to think so. My (obvious?) point is, if you make the stack different, and not just smaller by omitting optional features, then that defeats the point of wanting the Linux stack in the first place. Thanks, Richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/24] net, diet: Make TCP metrics optional
> You see, that's the point I'm trying to make, once it's upstream > then it's my problem. FWIW I don't think any of the changes I proposed would be likely to add lots of new bugs. Nothing was really adding any significant new logic, just doing less (modulo perhaps fib_list) Was that your main concern? I realize the many config options are something that could be consolidated to ease compile time testing. -Andi -- a...@linux.intel.com -- Speaking for myself only. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/24] net, diet: Make TCP metrics optional
> Can this at least be done without the combinatorial explosion in > number of configurations? As Yuchung pointed out these patches > introduce at least one unresolved configuration dependency. CONFIG_SMP > works quite well since with a single parameter we can enable/disable a > whole bunch of functionality in bulk, and it's quite clear that new > development cannot break smp or non-smp configurations. Maybe you want > something similar like CONFIG_NETWORK_SMALL? Yes I've considered this. I'm not sure SMP is good enough though, at some point we'll get tiny dual core systems. >From the 0/0: >>> Right now I'm using own Kconfigs for every removed features. I realize this somewhat increases the compile test matrix. It would be possible to hide some of the options and select them using higher level configurations like the ones listed above. I haven't done this in this version. <<< -Andi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/24] net, diet: Make TCP metrics optional
> So I think Dave is right > in rejecting anything that compromises the _quality_ of the stack. I don't think anything I removed compromised quality (modulo bugs) It's still a more-features-than-your-typical-BSD TCP/IP stack -Andi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/24] net, diet: Make TCP metrics optional
On Tue, May 06, 2014 at 11:58:38AM -0700, Tom Herbert wrote: > On Tue, May 6, 2014 at 11:32 AM, Andi Kleen wrote: > >> We simply can not compete with user space, as a programmer is free to > >> keep what he really wants/needs. > > > > Not true. > > > > With my patches and LTO Linux can be competive with LWIP+socket layer. > > (about 60K more text). And it's easier to use because it's just > > the standard interface. > > > >> I have started using linux on 386/486 pcs which had more than 2MB of > >> memory, it makes me sad we want linux-3.16 to run on this kind of > >> hardware, and consuming time to save few KB here and here. > > > > Linux has always been a system from very small to big. > > That's been one of its strengths. It is very adaptable. > > > > Many subsystems are very configurable for this. > > For example that is why we have both SLOB and SLUB. > > That is why we have NOMMU MM and lots of other tuning > > knobs for small systems. > > > > So if the other subsystems can do this, why should it be > > impossible for networking? > > > Can this at least be done without the combinatorial explosion in > number of configurations? As Yuchung pointed out these patches > introduce at least one unresolved configuration dependency. CONFIG_SMP > works quite well since with a single parameter we can enable/disable a > whole bunch of functionality in bulk, and it's quite clear that new > development cannot break smp or non-smp configurations. Maybe you want > something similar like CONFIG_NETWORK_SMALL? That seems completely reasonable. Likewise, for infrastructure that scales by CPU, keying off of CONFIG_NR_CPUS might make sense. I'd suggest inverting it, so that 'n' means "small" and 'y' means fully featured. Here's a rough description for a CONFIG_NETWORK_FULL: config NETWORK_FULL default y bool "Full-featured networking stack" if EMBEDDED --help-- Leave this option enabled for a full-featured networking stack, including features used by the vast majority of systems. Saying N here results in a minimal embedded networking stack, suitable only for the most memory-constrained and storage-constrained systems; the minimal stack removes many features, and optimizes for code and data size rather than performance. If in doubt, say Y here. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/24] net, diet: Make TCP metrics optional
On Tue, May 06, 2014 at 11:33:11AM -0700, Cong Wang wrote: > > So why bothers 3.15+ Linux kernel? Why not use an old kernel e.g. 2.4.x? > 2.4.x kernel doesn't have so many new features you want to get rid of here. If you compare a 3.x and a 2.4.x kernel with the same minimal feature set, you might see that the 3.x is bigger. Thanks, Richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/24] net, diet: Make TCP metrics optional
On Tue, May 06, 2014 at 09:41:08AM -0700, j...@joshtriplett.org wrote: > On Tue, May 06, 2014 at 11:59:41AM -0400, David Miller wrote: > > Making 2MB RAM machines today makes no sense at all. Besides cost, one of the main reasons for designing tiny systems today is battery life. Some devices cannot be recharged every week, like your smart phone must. > > The lowest end dirt cheap smartphone, something which fits on > > someone's pocket, has gigabytes of ram. Right, these low end smart phones are nicer than the DEC Alpha work stations we had at university. I would not call them "small" embedded systems. > Every KB of RAM costs real money and SoC die area (for eDRAM/eSRAM). > Look at how much cache low-end processors have, and imagine running > entirely out of *that*. Let's not surrender that entire class of > devices to VxWorks, FreeRTOS, and other painfully non-Linux systems, > when we already know it's possible to run Linux on them successfully. I have also been working on tiny system recently (and hope to get out of it soon ;). This whole IoT trend might just go away, I sure hope it does, but in general there is a growing need for tiny systems with excellent networking. Davem's attitude is understandable, and Linux should not be expected to fit into every last micro controller, but still I observe the kernel getting ever bigger, even in the most basic configurations. I don't think there is valid technical reason for bloat, but rather it is an issue that doesn't affect too many people. In any case I would really like to see the possibility of leaving pieces out for these tiny systems, but it would be a balancing act. On the one hand, we want the stable/powerful/wonderful Linux stack in our tiny systems. On the other hand, if we rip everything out to make it fit, then it is no longer the same thing. So I think Dave is right in rejecting anything that compromises the _quality_ of the stack. Off on a tangent: Regarding the multiplicity of RTOSs out there, all I can say is, they all suck, especially the ones you pay money for. It would be great to have a small Linux like OS for micro controllers and tiny micro processors. I have looked and looked for an open source, posix like alternative, but all I found was Nuttx, ActionOS, and RTEMS. I looked closely at the first two, and putting aside technical issues, neither seems to have any steam in terms of active development. RTEMS says it has a BSD stack, and it seems to have a respectable development effort, but I did not look too closely at it. There is a huge area out there (think of all the Cortex M3) that needs a real networking stack, but I don't see much hope. Minimizing Linux is a big PITA (tons of work), and building a suitably small OS from scratch is hopeless. As was said, it is easier just to buy a bigger memory. The people who can't or won't (who are also building the IoT) will just throw in some lwIP or uIP. You can imagine how secure these systems will be. Thanks, Richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/24] net, diet: Make TCP metrics optional
On Tue, May 6, 2014 at 11:32 AM, Andi Kleen wrote: >> We simply can not compete with user space, as a programmer is free to >> keep what he really wants/needs. > > Not true. > > With my patches and LTO Linux can be competive with LWIP+socket layer. > (about 60K more text). And it's easier to use because it's just > the standard interface. > >> I have started using linux on 386/486 pcs which had more than 2MB of >> memory, it makes me sad we want linux-3.16 to run on this kind of >> hardware, and consuming time to save few KB here and here. > > Linux has always been a system from very small to big. > That's been one of its strengths. It is very adaptable. > > Many subsystems are very configurable for this. > For example that is why we have both SLOB and SLUB. > That is why we have NOMMU MM and lots of other tuning > knobs for small systems. > > So if the other subsystems can do this, why should it be > impossible for networking? > Can this at least be done without the combinatorial explosion in number of configurations? As Yuchung pointed out these patches introduce at least one unresolved configuration dependency. CONFIG_SMP works quite well since with a single parameter we can enable/disable a whole bunch of functionality in bulk, and it's quite clear that new development cannot break smp or non-smp configurations. Maybe you want something similar like CONFIG_NETWORK_SMALL? Tom > -Andi > > -- > a...@linux.intel.com -- Speaking for myself only > -- > To unsubscribe from this list: send the line "unsubscribe netdev" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/24] net, diet: Make TCP metrics optional
> So why bothers 3.15+ Linux kernel? Why not use an old kernel e.g. 2.4.x? > 2.4.x kernel doesn't have so many new features you want to get rid of here. Nobody wants to be stuck on an ancient kernel forever. -Andi -- a...@linux.intel.com -- Speaking for myself only -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/24] net, diet: Make TCP metrics optional
On Tue, May 6, 2014 at 10:55 AM, wrote: > On Tue, May 06, 2014 at 01:16:43PM -0400, David Miller wrote: >> From: j...@joshtriplett.org >> 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. So why bothers 3.15+ Linux kernel? Why not use an old kernel e.g. 2.4.x? 2.4.x kernel doesn't have so many new features you want to get rid of here. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/24] net, diet: Make TCP metrics optional
> We simply can not compete with user space, as a programmer is free to > keep what he really wants/needs. Not true. With my patches and LTO Linux can be competive with LWIP+socket layer. (about 60K more text). And it's easier to use because it's just the standard interface. > I have started using linux on 386/486 pcs which had more than 2MB of > memory, it makes me sad we want linux-3.16 to run on this kind of > hardware, and consuming time to save few KB here and here. Linux has always been a system from very small to big. That's been one of its strengths. It is very adaptable. Many subsystems are very configurable for this. For example that is why we have both SLOB and SLUB. That is why we have NOMMU MM and lots of other tuning knobs for small systems. So if the other subsystems can do this, why should it be impossible for networking? -Andi -- a...@linux.intel.com -- Speaking for myself only -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/24] net, diet: Make TCP metrics optional
On Tue, May 06, 2014 at 10:12:11AM -0700, Rick Jones wrote: > On 05/06/2014 09:41 AM, j...@joshtriplett.org wrote: > >On Tue, May 06, 2014 at 11:59:41AM -0400, David Miller wrote: > >>Making 2MB RAM machines today makes no sense at all. > >> > >>The lowest end dirt cheap smartphone, something which fits on > >>someone's pocket, has gigabytes of ram. > > > >The lowest-end smartphone isn't anywhere close to "dirt cheap", and > >hardly counts as "embedded" at all anymore. Smartphones cost $100+; > >we're talking about systems in the low tens of dollars or less. These > >systems will have no graphics, no peripherals, and only one or two > >specific functions. The entirety of their functionality will likely > >consist of a single userspace program; they might not even have a PID 2. > >*That's* the kind of "embedded" we're talking about, not the > >supercomputers we carry around in our pockets. > > Would this be some sort of "Internet of Things" system? That's one of many buzzwords being used for this kind of system, sure. The "Internet of" part makes networking particularly important. - Josh Triplett -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/24] net, diet: Make TCP metrics optional
On Tue, May 06, 2014 at 01:16:43PM -0400, David Miller wrote: > From: j...@joshtriplett.org > 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/24] net, diet: Make TCP metrics optional
On Tue, May 06, 2014 at 10:03:24AM -0700, Eric Dumazet wrote: > On Tue, 2014-05-06 at 09:45 -0700, j...@joshtriplett.org wrote: > > > Sounds like we have some optimization to do, then; there's no > > fundamental unfixable reason for that delta. > > I think you have little idea of the reasons for this delta. I have a rather good idea, actually. > Some servers handle 10 millions of TCP flows, using as little as 1KB per > connection in user space, all included. > > Do you have an idea of how much memory is needed for 10 millions TCP > sockets in the kernel ? Too much. That's potentially fixable, but not if we start with the premise that it's impossible. - Josh Triplett -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/24] net, diet: Make TCP metrics optional
From: j...@joshtriplett.org Date: Tue, 6 May 2014 10:21:06 -0700 > On Tue, May 06, 2014 at 01:17:52PM -0400, David Miller wrote: >> From: j...@joshtriplett.org >> Date: Tue, 6 May 2014 09:45:46 -0700 >> >> > The kernel can do the same. Consider the idea of analyzing a set of >> > userspace programs, determining what kernel functionality they do and >> > don't need, feeding that information into the kernel build process, and >> > automatically dropping unused bits of the kernel. >> >> Please make sure I'm not on the list of people who see reports for >> bugs reported in that setup. >> >> Thanks :-) > > Fine by me. Just please allow such a setup to exist. :) You see, that's the point I'm trying to make, once it's upstream then it's my problem. You absolutely must consider the burdon you put upon upstream maintainers when you ask for things to be included. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/24] net, diet: Make TCP metrics optional
On Tue, May 06, 2014 at 01:17:52PM -0400, David Miller wrote: > From: j...@joshtriplett.org > Date: Tue, 6 May 2014 09:45:46 -0700 > > > The kernel can do the same. Consider the idea of analyzing a set of > > userspace programs, determining what kernel functionality they do and > > don't need, feeding that information into the kernel build process, and > > automatically dropping unused bits of the kernel. > > Please make sure I'm not on the list of people who see reports for > bugs reported in that setup. > > Thanks :-) Fine by me. Just please allow such a setup to exist. :) - Josh Triplett -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/24] net, diet: Make TCP metrics optional
From: j...@joshtriplett.org Date: Tue, 6 May 2014 09:45:46 -0700 > The kernel can do the same. Consider the idea of analyzing a set of > userspace programs, determining what kernel functionality they do and > don't need, feeding that information into the kernel build process, and > automatically dropping unused bits of the kernel. Please make sure I'm not on the list of people who see reports for bugs reported in that setup. Thanks :-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/24] net, diet: Make TCP metrics optional
From: j...@joshtriplett.org 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. And last time I checked Linux wasn't a special purpose operating system, but lucky for you I hear there are lots of those around. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/24] net, diet: Make TCP metrics optional
From: Eric Dumazet Date: Tue, 06 May 2014 09:39:19 -0700 > I have started using linux on 386/486 pcs which had more than 2MB of > memory, it makes me sad we want linux-3.16 to run on this kind of > hardware, and consuming time to save few KB here and here. +1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/24] net, diet: Make TCP metrics optional
On 05/06/2014 09:41 AM, j...@joshtriplett.org wrote: On Tue, May 06, 2014 at 11:59:41AM -0400, David Miller wrote: Making 2MB RAM machines today makes no sense at all. The lowest end dirt cheap smartphone, something which fits on someone's pocket, has gigabytes of ram. The lowest-end smartphone isn't anywhere close to "dirt cheap", and hardly counts as "embedded" at all anymore. Smartphones cost $100+; we're talking about systems in the low tens of dollars or less. These systems will have no graphics, no peripherals, and only one or two specific functions. The entirety of their functionality will likely consist of a single userspace program; they might not even have a PID 2. *That's* the kind of "embedded" we're talking about, not the supercomputers we carry around in our pockets. Would this be some sort of "Internet of Things" system? rick jones -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/24] net, diet: Make TCP metrics optional
On Tue, 2014-05-06 at 09:45 -0700, j...@joshtriplett.org wrote: > Sounds like we have some optimization to do, then; there's no > fundamental unfixable reason for that delta. I think you have little idea of the reasons for this delta. Some servers handle 10 millions of TCP flows, using as little as 1KB per connection in user space, all included. Do you have an idea of how much memory is needed for 10 millions TCP sockets in the kernel ? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/24] net, diet: Make TCP metrics optional
On Tue, May 06, 2014 at 09:39:19AM -0700, Eric Dumazet wrote: > On Tue, 2014-05-06 at 08:57 -0700, j...@joshtriplett.org wrote: > > > A NAK isn't going to cut it, here; tiny Linux systems are going to > > exist, and they shouldn't have to maintain a long-term out-of-tree fork > > or use crazy things like LWIP. > > What's wrong with user space implementations of networking stacks ? What's wrong with the kernel implementation? > For many usages, it can bring 10 times the performance of having user > application and kernel sockets. Sounds like we have some optimization to do, then; there's no fundamental unfixable reason for that delta. > In any cases, we do not model kernel implementations to 'compete' with > user space. > > We simply can not compete with user space, as a programmer is free to > keep what he really wants/needs. The kernel can do the same. Consider the idea of analyzing a set of userspace programs, determining what kernel functionality they do and don't need, feeding that information into the kernel build process, and automatically dropping unused bits of the kernel. Ideally, that kind of process would support eliminating kernel config options that just select userspace-visible interfaces, leaving only the kernel config options that change how those interfaces behave (size/performance/feature tradeoffs). - Josh Triplett -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/24] net, diet: Make TCP metrics optional
On Tue, May 06, 2014 at 11:59:41AM -0400, David Miller wrote: > From: j...@joshtriplett.org > Date: Tue, 6 May 2014 08:57:03 -0700 > > > On Mon, May 05, 2014 at 11:23:27PM -0400, David Miller wrote: > >> From: Andi Kleen > >> Date: Tue, 6 May 2014 05:21:14 +0200 > >> > >> > What parts would you remove to get the foot print down for a 2MB > >> > single purpose machine? > >> > >> I wouldn't use Linux, end of story. > >> > >> Maybe two decades ago, but not now, those days are over. > > > > That's a self-fulfilling prophecy: > > Making 2MB RAM machines today makes no sense at all. > > The lowest end dirt cheap smartphone, something which fits on > someone's pocket, has gigabytes of ram. The lowest-end smartphone isn't anywhere close to "dirt cheap", and hardly counts as "embedded" at all anymore. Smartphones cost $100+; we're talking about systems in the low tens of dollars or less. These systems will have no graphics, no peripherals, and only one or two specific functions. The entirety of their functionality will likely consist of a single userspace program; they might not even have a PID 2. *That's* the kind of "embedded" we're talking about, not the supercomputers we carry around in our pockets. Every KB of RAM costs real money and SoC die area (for eDRAM/eSRAM). Look at how much cache low-end processors have, and imagine running entirely out of *that*. Let's not surrender that entire class of devices to VxWorks, FreeRTOS, and other painfully non-Linux systems, when we already know it's possible to run Linux on them successfully. - Josh Triplett -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/24] net, diet: Make TCP metrics optional
On Tue, 2014-05-06 at 08:57 -0700, j...@joshtriplett.org wrote: > A NAK isn't going to cut it, here; tiny Linux systems are going to > exist, and they shouldn't have to maintain a long-term out-of-tree fork > or use crazy things like LWIP. What's wrong with user space implementations of networking stacks ? For many usages, it can bring 10 times the performance of having user application and kernel sockets. In any cases, we do not model kernel implementations to 'compete' with user space. We simply can not compete with user space, as a programmer is free to keep what he really wants/needs. I have started using linux on 386/486 pcs which had more than 2MB of memory, it makes me sad we want linux-3.16 to run on this kind of hardware, and consuming time to save few KB here and here. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/24] net, diet: Make TCP metrics optional
From: j...@joshtriplett.org Date: Tue, 6 May 2014 08:57:03 -0700 > On Mon, May 05, 2014 at 11:23:27PM -0400, David Miller wrote: >> From: Andi Kleen >> Date: Tue, 6 May 2014 05:21:14 +0200 >> >> > What parts would you remove to get the foot print down for a 2MB >> > single purpose machine? >> >> I wouldn't use Linux, end of story. >> >> Maybe two decades ago, but not now, those days are over. > > That's a self-fulfilling prophecy: Making 2MB RAM machines today makes no sense at all. The lowest end dirt cheap smartphone, something which fits on someone's pocket, has gigabytes of ram. The only entity looking backwards are the people making these improperly provisioned systems. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/24] net, diet: Make TCP metrics optional
On Mon, May 05, 2014 at 11:23:27PM -0400, David Miller wrote: > From: Andi Kleen > Date: Tue, 6 May 2014 05:21:14 +0200 > > > What parts would you remove to get the foot print down for a 2MB > > single purpose machine? > > I wouldn't use Linux, end of story. > > Maybe two decades ago, but not now, those days are over. That's a self-fulfilling prophecy: if you and others assume that Linux should not run on such machines, then size regressions will continue to happen, and patches to make Linux continue running on such systems will not make it into the kernel. There are real people and products intending to use Linux on incredibly tiny embedded systems; Tom already posted about one in this thread. Personally, I'd much rather see Linux on such systems rather than some crazy embedded (often proprietary) OS, and so would many other people. A NAK isn't going to cut it, here; tiny Linux systems are going to exist, and they shouldn't have to maintain a long-term out-of-tree fork or use crazy things like LWIP. I understand that you want to reduce maintenance effort and Kconfig option proliferation; that's a very real concern. It's likely possible to address those concerns while still producing a usable minimal version of the networking stack, if you'd be willing to provide feedback and support iteration of patches like these. Would you be interested in discussing this at Kernel Summit, perhaps? Would that help to hammer out a plan for this? - Josh Triplett -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/24] net, diet: Make TCP metrics optional
On Tue, May 06, 2014 at 05:11:17PM -0400, David Miller wrote: From: j...@joshtriplett.org Date: Tue, 6 May 2014 14:08:15 -0700 On Tue, May 06, 2014 at 04:44:10PM -0400, David Miller wrote: From: Cong Wang xiyou.wangc...@gmail.com Date: Tue, 6 May 2014 11:33:11 -0700 So why bothers 3.15+ Linux kernel? Why not use an old kernel e.g. 2.4.x? 2.4.x kernel doesn't have so many new features you want to get rid of here. +1 You've got to be kidding. Using 2.4 for a new network-connected device, today? With all of its potential security holes that nobody is paying attention to? Easier to fork 3.15 and trim it down than to do *that*. And there *are* a huge number of useful features in 3.15+, not least of which drivers for current hardware. So you're saying that the 2.4.x -stable maintainer did a shitty job and his work is worthless? There's a difference between maintaining 2.4.x for all the existing users who can't or won't upgrade, and introducing a *new* product shipping with 2.4.x. There's something very wrong if 2.4.x works for cases that 3.x doesn't; that would be a serious regression. - Josh Triplett -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/24] net, diet: Make TCP metrics optional
On Tue, 2014-05-06 at 15:50 -0700, j...@joshtriplett.org wrote: There's something very wrong if 2.4.x works for cases that 3.x doesn't; that would be a serious regression. You'll have to ask Linus to bring back i386 support then, I believe it was removed in 3.8 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/24] net, diet: Make TCP metrics optional
On Tue, 2014-05-06 at 14:05 -0700, Andi Kleen wrote: - Make GRO optional. This is purely a performance feature for high bandwidth. Make this properly then, instead of relying on LTO. We did preliminary work to put this stuff in separate files, but its not complete yet. tcpv4_offload has pointers to tcp4_gro_receive() and tcp4_gro_complete() Is LTO smart enough to understand this will never be called, and do proper code elimination of whole _gro_ helpers ? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/24] net, diet: Make TCP metrics optional
On Tue, May 06, 2014 at 04:29:39PM -0700, Eric Dumazet wrote: On Tue, 2014-05-06 at 14:05 -0700, Andi Kleen wrote: - Make GRO optional. This is purely a performance feature for high bandwidth. Make this properly then, instead of relying on LTO. We did preliminary work to put this stuff in separate files, but its not complete yet. FWIW doesn't matter for LTO. tcpv4_offload has pointers to tcp4_gro_receive() and tcp4_gro_complete() Is LTO smart enough to understand this will never be called, and do proper code elimination of whole _gro_ helpers ? When there are pointers in static objects it cannot eliminate it for C (it may work for C++) However if you just remove the pointer it'll remove the rest. -Andi -- a...@linux.intel.com -- Speaking for myself only. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/24] net, diet: Make TCP metrics optional
On Mon, May 05, 2014 at 11:23:27PM -0400, David Miller wrote: From: Andi Kleen a...@firstfloor.org Date: Tue, 6 May 2014 05:21:14 +0200 What parts would you remove to get the foot print down for a 2MB single purpose machine? I wouldn't use Linux, end of story. Maybe two decades ago, but not now, those days are over. That's a self-fulfilling prophecy: if you and others assume that Linux should not run on such machines, then size regressions will continue to happen, and patches to make Linux continue running on such systems will not make it into the kernel. There are real people and products intending to use Linux on incredibly tiny embedded systems; Tom already posted about one in this thread. Personally, I'd much rather see Linux on such systems rather than some crazy embedded (often proprietary) OS, and so would many other people. A NAK isn't going to cut it, here; tiny Linux systems are going to exist, and they shouldn't have to maintain a long-term out-of-tree fork or use crazy things like LWIP. I understand that you want to reduce maintenance effort and Kconfig option proliferation; that's a very real concern. It's likely possible to address those concerns while still producing a usable minimal version of the networking stack, if you'd be willing to provide feedback and support iteration of patches like these. Would you be interested in discussing this at Kernel Summit, perhaps? Would that help to hammer out a plan for this? - Josh Triplett -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/24] net, diet: Make TCP metrics optional
From: j...@joshtriplett.org Date: Tue, 6 May 2014 08:57:03 -0700 On Mon, May 05, 2014 at 11:23:27PM -0400, David Miller wrote: From: Andi Kleen a...@firstfloor.org Date: Tue, 6 May 2014 05:21:14 +0200 What parts would you remove to get the foot print down for a 2MB single purpose machine? I wouldn't use Linux, end of story. Maybe two decades ago, but not now, those days are over. That's a self-fulfilling prophecy: Making 2MB RAM machines today makes no sense at all. The lowest end dirt cheap smartphone, something which fits on someone's pocket, has gigabytes of ram. The only entity looking backwards are the people making these improperly provisioned systems. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/24] net, diet: Make TCP metrics optional
On Tue, 2014-05-06 at 08:57 -0700, j...@joshtriplett.org wrote: A NAK isn't going to cut it, here; tiny Linux systems are going to exist, and they shouldn't have to maintain a long-term out-of-tree fork or use crazy things like LWIP. What's wrong with user space implementations of networking stacks ? For many usages, it can bring 10 times the performance of having user application and kernel sockets. In any cases, we do not model kernel implementations to 'compete' with user space. We simply can not compete with user space, as a programmer is free to keep what he really wants/needs. I have started using linux on 386/486 pcs which had more than 2MB of memory, it makes me sad we want linux-3.16 to run on this kind of hardware, and consuming time to save few KB here and here. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/24] net, diet: Make TCP metrics optional
On Tue, May 06, 2014 at 11:59:41AM -0400, David Miller wrote: From: j...@joshtriplett.org Date: Tue, 6 May 2014 08:57:03 -0700 On Mon, May 05, 2014 at 11:23:27PM -0400, David Miller wrote: From: Andi Kleen a...@firstfloor.org Date: Tue, 6 May 2014 05:21:14 +0200 What parts would you remove to get the foot print down for a 2MB single purpose machine? I wouldn't use Linux, end of story. Maybe two decades ago, but not now, those days are over. That's a self-fulfilling prophecy: Making 2MB RAM machines today makes no sense at all. The lowest end dirt cheap smartphone, something which fits on someone's pocket, has gigabytes of ram. The lowest-end smartphone isn't anywhere close to dirt cheap, and hardly counts as embedded at all anymore. Smartphones cost $100+; we're talking about systems in the low tens of dollars or less. These systems will have no graphics, no peripherals, and only one or two specific functions. The entirety of their functionality will likely consist of a single userspace program; they might not even have a PID 2. *That's* the kind of embedded we're talking about, not the supercomputers we carry around in our pockets. Every KB of RAM costs real money and SoC die area (for eDRAM/eSRAM). Look at how much cache low-end processors have, and imagine running entirely out of *that*. Let's not surrender that entire class of devices to VxWorks, FreeRTOS, and other painfully non-Linux systems, when we already know it's possible to run Linux on them successfully. - Josh Triplett -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/24] net, diet: Make TCP metrics optional
On Tue, May 06, 2014 at 09:39:19AM -0700, Eric Dumazet wrote: On Tue, 2014-05-06 at 08:57 -0700, j...@joshtriplett.org wrote: A NAK isn't going to cut it, here; tiny Linux systems are going to exist, and they shouldn't have to maintain a long-term out-of-tree fork or use crazy things like LWIP. What's wrong with user space implementations of networking stacks ? What's wrong with the kernel implementation? For many usages, it can bring 10 times the performance of having user application and kernel sockets. Sounds like we have some optimization to do, then; there's no fundamental unfixable reason for that delta. In any cases, we do not model kernel implementations to 'compete' with user space. We simply can not compete with user space, as a programmer is free to keep what he really wants/needs. The kernel can do the same. Consider the idea of analyzing a set of userspace programs, determining what kernel functionality they do and don't need, feeding that information into the kernel build process, and automatically dropping unused bits of the kernel. Ideally, that kind of process would support eliminating kernel config options that just select userspace-visible interfaces, leaving only the kernel config options that change how those interfaces behave (size/performance/feature tradeoffs). - Josh Triplett -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/24] net, diet: Make TCP metrics optional
On Tue, 2014-05-06 at 09:45 -0700, j...@joshtriplett.org wrote: Sounds like we have some optimization to do, then; there's no fundamental unfixable reason for that delta. I think you have little idea of the reasons for this delta. Some servers handle 10 millions of TCP flows, using as little as 1KB per connection in user space, all included. Do you have an idea of how much memory is needed for 10 millions TCP sockets in the kernel ? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/24] net, diet: Make TCP metrics optional
On 05/06/2014 09:41 AM, j...@joshtriplett.org wrote: On Tue, May 06, 2014 at 11:59:41AM -0400, David Miller wrote: Making 2MB RAM machines today makes no sense at all. The lowest end dirt cheap smartphone, something which fits on someone's pocket, has gigabytes of ram. The lowest-end smartphone isn't anywhere close to dirt cheap, and hardly counts as embedded at all anymore. Smartphones cost $100+; we're talking about systems in the low tens of dollars or less. These systems will have no graphics, no peripherals, and only one or two specific functions. The entirety of their functionality will likely consist of a single userspace program; they might not even have a PID 2. *That's* the kind of embedded we're talking about, not the supercomputers we carry around in our pockets. Would this be some sort of Internet of Things system? rick jones -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/24] net, diet: Make TCP metrics optional
From: Eric Dumazet eric.duma...@gmail.com Date: Tue, 06 May 2014 09:39:19 -0700 I have started using linux on 386/486 pcs which had more than 2MB of memory, it makes me sad we want linux-3.16 to run on this kind of hardware, and consuming time to save few KB here and here. +1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/24] net, diet: Make TCP metrics optional
From: j...@joshtriplett.org 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. And last time I checked Linux wasn't a special purpose operating system, but lucky for you I hear there are lots of those around. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/24] net, diet: Make TCP metrics optional
From: j...@joshtriplett.org Date: Tue, 6 May 2014 09:45:46 -0700 The kernel can do the same. Consider the idea of analyzing a set of userspace programs, determining what kernel functionality they do and don't need, feeding that information into the kernel build process, and automatically dropping unused bits of the kernel. Please make sure I'm not on the list of people who see reports for bugs reported in that setup. Thanks :-) -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/24] net, diet: Make TCP metrics optional
On Tue, May 06, 2014 at 01:17:52PM -0400, David Miller wrote: From: j...@joshtriplett.org Date: Tue, 6 May 2014 09:45:46 -0700 The kernel can do the same. Consider the idea of analyzing a set of userspace programs, determining what kernel functionality they do and don't need, feeding that information into the kernel build process, and automatically dropping unused bits of the kernel. Please make sure I'm not on the list of people who see reports for bugs reported in that setup. Thanks :-) Fine by me. Just please allow such a setup to exist. :) - Josh Triplett -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/24] net, diet: Make TCP metrics optional
From: j...@joshtriplett.org Date: Tue, 6 May 2014 10:21:06 -0700 On Tue, May 06, 2014 at 01:17:52PM -0400, David Miller wrote: From: j...@joshtriplett.org Date: Tue, 6 May 2014 09:45:46 -0700 The kernel can do the same. Consider the idea of analyzing a set of userspace programs, determining what kernel functionality they do and don't need, feeding that information into the kernel build process, and automatically dropping unused bits of the kernel. Please make sure I'm not on the list of people who see reports for bugs reported in that setup. Thanks :-) Fine by me. Just please allow such a setup to exist. :) You see, that's the point I'm trying to make, once it's upstream then it's my problem. You absolutely must consider the burdon you put upon upstream maintainers when you ask for things to be included. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/24] net, diet: Make TCP metrics optional
On Tue, May 06, 2014 at 10:03:24AM -0700, Eric Dumazet wrote: On Tue, 2014-05-06 at 09:45 -0700, j...@joshtriplett.org wrote: Sounds like we have some optimization to do, then; there's no fundamental unfixable reason for that delta. I think you have little idea of the reasons for this delta. I have a rather good idea, actually. Some servers handle 10 millions of TCP flows, using as little as 1KB per connection in user space, all included. Do you have an idea of how much memory is needed for 10 millions TCP sockets in the kernel ? Too much. That's potentially fixable, but not if we start with the premise that it's impossible. - Josh Triplett -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/24] net, diet: Make TCP metrics optional
On Tue, May 06, 2014 at 01:16:43PM -0400, David Miller wrote: From: j...@joshtriplett.org 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/24] net, diet: Make TCP metrics optional
On Tue, May 06, 2014 at 10:12:11AM -0700, Rick Jones wrote: On 05/06/2014 09:41 AM, j...@joshtriplett.org wrote: On Tue, May 06, 2014 at 11:59:41AM -0400, David Miller wrote: Making 2MB RAM machines today makes no sense at all. The lowest end dirt cheap smartphone, something which fits on someone's pocket, has gigabytes of ram. The lowest-end smartphone isn't anywhere close to dirt cheap, and hardly counts as embedded at all anymore. Smartphones cost $100+; we're talking about systems in the low tens of dollars or less. These systems will have no graphics, no peripherals, and only one or two specific functions. The entirety of their functionality will likely consist of a single userspace program; they might not even have a PID 2. *That's* the kind of embedded we're talking about, not the supercomputers we carry around in our pockets. Would this be some sort of Internet of Things system? That's one of many buzzwords being used for this kind of system, sure. The Internet of part makes networking particularly important. - Josh Triplett -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/24] net, diet: Make TCP metrics optional
We simply can not compete with user space, as a programmer is free to keep what he really wants/needs. Not true. With my patches and LTO Linux can be competive with LWIP+socket layer. (about 60K more text). And it's easier to use because it's just the standard interface. I have started using linux on 386/486 pcs which had more than 2MB of memory, it makes me sad we want linux-3.16 to run on this kind of hardware, and consuming time to save few KB here and here. Linux has always been a system from very small to big. That's been one of its strengths. It is very adaptable. Many subsystems are very configurable for this. For example that is why we have both SLOB and SLUB. That is why we have NOMMU MM and lots of other tuning knobs for small systems. So if the other subsystems can do this, why should it be impossible for networking? -Andi -- a...@linux.intel.com -- Speaking for myself only -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/24] net, diet: Make TCP metrics optional
On Tue, May 6, 2014 at 10:55 AM, j...@joshtriplett.org wrote: On Tue, May 06, 2014 at 01:16:43PM -0400, David Miller wrote: From: j...@joshtriplett.org 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. So why bothers 3.15+ Linux kernel? Why not use an old kernel e.g. 2.4.x? 2.4.x kernel doesn't have so many new features you want to get rid of here. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/24] net, diet: Make TCP metrics optional
So why bothers 3.15+ Linux kernel? Why not use an old kernel e.g. 2.4.x? 2.4.x kernel doesn't have so many new features you want to get rid of here. Nobody wants to be stuck on an ancient kernel forever. -Andi -- a...@linux.intel.com -- Speaking for myself only -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/24] net, diet: Make TCP metrics optional
On Tue, May 6, 2014 at 11:32 AM, Andi Kleen a...@linux.intel.com wrote: We simply can not compete with user space, as a programmer is free to keep what he really wants/needs. Not true. With my patches and LTO Linux can be competive with LWIP+socket layer. (about 60K more text). And it's easier to use because it's just the standard interface. I have started using linux on 386/486 pcs which had more than 2MB of memory, it makes me sad we want linux-3.16 to run on this kind of hardware, and consuming time to save few KB here and here. Linux has always been a system from very small to big. That's been one of its strengths. It is very adaptable. Many subsystems are very configurable for this. For example that is why we have both SLOB and SLUB. That is why we have NOMMU MM and lots of other tuning knobs for small systems. So if the other subsystems can do this, why should it be impossible for networking? Can this at least be done without the combinatorial explosion in number of configurations? As Yuchung pointed out these patches introduce at least one unresolved configuration dependency. CONFIG_SMP works quite well since with a single parameter we can enable/disable a whole bunch of functionality in bulk, and it's quite clear that new development cannot break smp or non-smp configurations. Maybe you want something similar like CONFIG_NETWORK_SMALL? Tom -Andi -- a...@linux.intel.com -- Speaking for myself only -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/24] net, diet: Make TCP metrics optional
On Tue, May 06, 2014 at 09:41:08AM -0700, j...@joshtriplett.org wrote: On Tue, May 06, 2014 at 11:59:41AM -0400, David Miller wrote: Making 2MB RAM machines today makes no sense at all. Besides cost, one of the main reasons for designing tiny systems today is battery life. Some devices cannot be recharged every week, like your smart phone must. The lowest end dirt cheap smartphone, something which fits on someone's pocket, has gigabytes of ram. Right, these low end smart phones are nicer than the DEC Alpha work stations we had at university. I would not call them small embedded systems. Every KB of RAM costs real money and SoC die area (for eDRAM/eSRAM). Look at how much cache low-end processors have, and imagine running entirely out of *that*. Let's not surrender that entire class of devices to VxWorks, FreeRTOS, and other painfully non-Linux systems, when we already know it's possible to run Linux on them successfully. I have also been working on tiny system recently (and hope to get out of it soon ;). This whole IoT trend might just go away, I sure hope it does, but in general there is a growing need for tiny systems with excellent networking. Davem's attitude is understandable, and Linux should not be expected to fit into every last micro controller, but still I observe the kernel getting ever bigger, even in the most basic configurations. I don't think there is valid technical reason for bloat, but rather it is an issue that doesn't affect too many people. In any case I would really like to see the possibility of leaving pieces out for these tiny systems, but it would be a balancing act. On the one hand, we want the stable/powerful/wonderful Linux stack in our tiny systems. On the other hand, if we rip everything out to make it fit, then it is no longer the same thing. So I think Dave is right in rejecting anything that compromises the _quality_ of the stack. Off on a tangent: Regarding the multiplicity of RTOSs out there, all I can say is, they all suck, especially the ones you pay money for. It would be great to have a small Linux like OS for micro controllers and tiny micro processors. I have looked and looked for an open source, posix like alternative, but all I found was Nuttx, ActionOS, and RTEMS. I looked closely at the first two, and putting aside technical issues, neither seems to have any steam in terms of active development. RTEMS says it has a BSD stack, and it seems to have a respectable development effort, but I did not look too closely at it. There is a huge area out there (think of all the Cortex M3) that needs a real networking stack, but I don't see much hope. Minimizing Linux is a big PITA (tons of work), and building a suitably small OS from scratch is hopeless. As was said, it is easier just to buy a bigger memory. The people who can't or won't (who are also building the IoT) will just throw in some lwIP or uIP. You can imagine how secure these systems will be. Thanks, Richard -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/24] net, diet: Make TCP metrics optional
On Tue, May 06, 2014 at 11:33:11AM -0700, Cong Wang wrote: So why bothers 3.15+ Linux kernel? Why not use an old kernel e.g. 2.4.x? 2.4.x kernel doesn't have so many new features you want to get rid of here. If you compare a 3.x and a 2.4.x kernel with the same minimal feature set, you might see that the 3.x is bigger. Thanks, Richard -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/24] net, diet: Make TCP metrics optional
On Tue, May 06, 2014 at 11:58:38AM -0700, Tom Herbert wrote: On Tue, May 6, 2014 at 11:32 AM, Andi Kleen a...@linux.intel.com wrote: We simply can not compete with user space, as a programmer is free to keep what he really wants/needs. Not true. With my patches and LTO Linux can be competive with LWIP+socket layer. (about 60K more text). And it's easier to use because it's just the standard interface. I have started using linux on 386/486 pcs which had more than 2MB of memory, it makes me sad we want linux-3.16 to run on this kind of hardware, and consuming time to save few KB here and here. Linux has always been a system from very small to big. That's been one of its strengths. It is very adaptable. Many subsystems are very configurable for this. For example that is why we have both SLOB and SLUB. That is why we have NOMMU MM and lots of other tuning knobs for small systems. So if the other subsystems can do this, why should it be impossible for networking? Can this at least be done without the combinatorial explosion in number of configurations? As Yuchung pointed out these patches introduce at least one unresolved configuration dependency. CONFIG_SMP works quite well since with a single parameter we can enable/disable a whole bunch of functionality in bulk, and it's quite clear that new development cannot break smp or non-smp configurations. Maybe you want something similar like CONFIG_NETWORK_SMALL? That seems completely reasonable. Likewise, for infrastructure that scales by CPU, keying off of CONFIG_NR_CPUS might make sense. I'd suggest inverting it, so that 'n' means small and 'y' means fully featured. Here's a rough description for a CONFIG_NETWORK_FULL: config NETWORK_FULL default y bool Full-featured networking stack if EMBEDDED --help-- Leave this option enabled for a full-featured networking stack, including features used by the vast majority of systems. Saying N here results in a minimal embedded networking stack, suitable only for the most memory-constrained and storage-constrained systems; the minimal stack removes many features, and optimizes for code and data size rather than performance. If in doubt, say Y here. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/24] net, diet: Make TCP metrics optional
So I think Dave is right in rejecting anything that compromises the _quality_ of the stack. I don't think anything I removed compromised quality (modulo bugs) It's still a more-features-than-your-typical-BSD TCP/IP stack -Andi -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/24] net, diet: Make TCP metrics optional
Can this at least be done without the combinatorial explosion in number of configurations? As Yuchung pointed out these patches introduce at least one unresolved configuration dependency. CONFIG_SMP works quite well since with a single parameter we can enable/disable a whole bunch of functionality in bulk, and it's quite clear that new development cannot break smp or non-smp configurations. Maybe you want something similar like CONFIG_NETWORK_SMALL? Yes I've considered this. I'm not sure SMP is good enough though, at some point we'll get tiny dual core systems. From the 0/0: Right now I'm using own Kconfigs for every removed features. I realize this somewhat increases the compile test matrix. It would be possible to hide some of the options and select them using higher level configurations like the ones listed above. I haven't done this in this version. -Andi -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/24] net, diet: Make TCP metrics optional
You see, that's the point I'm trying to make, once it's upstream then it's my problem. FWIW I don't think any of the changes I proposed would be likely to add lots of new bugs. Nothing was really adding any significant new logic, just doing less (modulo perhaps fib_list) Was that your main concern? I realize the many config options are something that could be consolidated to ease compile time testing. -Andi -- a...@linux.intel.com -- Speaking for myself only. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/24] net, diet: Make TCP metrics optional
On Tue, May 06, 2014 at 12:50:49PM -0700, Andi Kleen wrote: So I think Dave is right in rejecting anything that compromises the _quality_ of the stack. I don't think anything I removed compromised quality (modulo bugs) It's still a more-features-than-your-typical-BSD TCP/IP stack But Dave seems to think so. My (obvious?) point is, if you make the stack different, and not just smaller by omitting optional features, then that defeats the point of wanting the Linux stack in the first place. Thanks, Richard -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/24] net, diet: Make TCP metrics optional
On Tue, May 06, 2014 at 01:25:01PM -0400, David Miller wrote: From: j...@joshtriplett.org Date: Tue, 6 May 2014 10:21:06 -0700 On Tue, May 06, 2014 at 01:17:52PM -0400, David Miller wrote: From: j...@joshtriplett.org Date: Tue, 6 May 2014 09:45:46 -0700 The kernel can do the same. Consider the idea of analyzing a set of userspace programs, determining what kernel functionality they do and don't need, feeding that information into the kernel build process, and automatically dropping unused bits of the kernel. Please make sure I'm not on the list of people who see reports for bugs reported in that setup. Thanks :-) Fine by me. Just please allow such a setup to exist. :) You see, that's the point I'm trying to make, once it's upstream then it's my problem. You absolutely must consider the burdon you put upon upstream maintainers when you ask for things to be included. Absolutely. And Andi and I are both interested in working *with* you to find a way to run on tiny embedded systems *without* necessarily introducing excessive proliferation of configuration options or unnecessarily increasing your support burden. For instance, it's easy enough to key some options off of CONFIG_NR_CPUS (such as data structure sizes), or introduce a big config switch (CONFIG_NETWORK_FULL=n or similar) that controls all of these cases rather than having option for each. That would not be hard to supply in a v2 of this patch series. And if you're asking for someone to help pay attention to bug reports so you don't have to, that's reasonable as well; just like you probably have a stock response for that's a crazy distro kernel, ask them about it and not me, you could have a stock response for that kernel has the crazy embedded option turned on, ask the embedded people about it and not me. It doesn't just have to be *your* problem alone. 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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/24] net, diet: Make TCP metrics optional
On Tue, 2014-05-06 at 11:32 -0700, Andi Kleen wrote: We simply can not compete with user space, as a programmer is free to keep what he really wants/needs. Not true. You can shake the kernel as much as you want, you wont make : - a TCP socket - a dentry - an inode - a file structure - eventpoll structures (assuming epoll use) - 2 dst per flow. In 1024 bytes of memory, and keep an efficient kernel to handle arbitrary number of sockets using the venerable and slow BSD socket api. I was objecting to the crazy things like LWIP comment from Josh, not to your patches in general. I actually took a look at them but stopped at patch 22 Adding ~1000 lines of code to save few KB was the point I gave up. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/24] net, diet: Make TCP metrics optional
On Tue, May 06, 2014 at 01:17:58PM -0700, Eric Dumazet wrote: On Tue, 2014-05-06 at 11:32 -0700, Andi Kleen wrote: We simply can not compete with user space, as a programmer is free to keep what he really wants/needs. Not true. You can shake the kernel as much as you want, you wont make : - a TCP socket - a dentry - an inode - a file structure - eventpoll structures (assuming epoll use) - 2 dst per flow. In 1024 bytes of memory, and keep an efficient kernel to handle arbitrary number of sockets using the venerable and slow BSD socket api. I was objecting to the crazy things like LWIP comment from Josh, not to your patches in general. My primary statement was that it's crazy to use something like LWIP just because you want a *tiny* system. We could argue about using LWIP because you want a massively scalable system, or one that more closely couples userspace and the kernel, but that's not the current goal in any case. So let's drop that branch of the thread. :) I actually took a look at them but stopped at patch 22 Adding ~1000 lines of code to save few KB was the point I gave up. Please consider ignoring that one and reading the rest; we could always handle the routing table issue separately. - Josh Triplett -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/24] net, diet: Make TCP metrics optional
In 1024 bytes of memory, and keep an efficient kernel to handle arbitrary number of sockets using the venerable and slow BSD socket api. I agree running in 1024 bytes would be challenging. Adding ~1000 lines of code to save few KB was the point I gave up. You're refering to fib_list? It currently has some duplicated code (this could/should be fixed). Or we could drop it, I suppose, if really everyone hates it. (I thought it was a cute idea, but I'm biased :-) Total it is saving 350k, about 30% of the total text size of the mini kernel (plus some dynamic savings) with networking. I would be happy to fix any reasonable objection. But fundamental I don't care about anything smaller than my smart phone type arguments are not particularly constructive. -Andi -- a...@linux.intel.com -- Speaking for myself only -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/24] net, diet: Make TCP metrics optional
And if you're asking for someone to help pay attention to bug reports so you don't have to, that's reasonable as well; just like you probably have a stock response for that's a crazy distro kernel, ask them about it and not me, you could have a stock response for that kernel has the crazy embedded option turned on, ask the embedded people about it and not me. It doesn't just have to be *your* problem alone. We could add a tainted flag for these configurations and a message at bootup to make it obvious in bug reports. Would that help? -Andi -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/24] net, diet: Make TCP metrics optional
From: Cong Wang xiyou.wangc...@gmail.com Date: Tue, 6 May 2014 11:33:11 -0700 So why bothers 3.15+ Linux kernel? Why not use an old kernel e.g. 2.4.x? 2.4.x kernel doesn't have so many new features you want to get rid of here. +1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
