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 poste
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 eD
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
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
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 p
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 unsub
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
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 no
> 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
> diff
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, yo
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-Li
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
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 poi
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
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+ L
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 h
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
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 (
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.ke
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 th
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.o
> 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
> cr
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
> 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 cu
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 wan
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
-
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
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
> 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 con
> 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 func
> 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 lin
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 competiv
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 migh
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 canno
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 b
> 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 l
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 D
> 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 usi
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
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 h
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
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 progr
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, fe
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
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 a
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: se
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 smartpho
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
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 thin
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
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 networkin
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?
>>
>
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 n
On Mon, 2014-05-05 at 23:23 -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, tho
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.
--
To unsubscribe from this list: send the line "unsubs
On Mon, May 05, 2014 at 11:12:29PM -0400, 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 y
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.
I'm not applying this.
--
To uns
> > +config TCP_METRICS
> > + bool "Report TCP metrics over netlink"
> > + ---help---
> > + Enable support in TCP to save host information between different
> > + connections.
> Please add that "Certain TCP features such as active TCP Fast Open
> depends on this."
I
On Mon, May 5, 2014 at 3:25 PM, Andi Kleen wrote:
> From: Andi Kleen
>
> This is all the code that saves connection information
> between different sockets. Not really essential for
> small systems.
>
> Saves about 5.5k text
>
>textdata bss dec hex filename
> 492952 19571
From: Andi Kleen
This is all the code that saves connection information
between different sockets. Not really essential for
small systems.
Saves about 5.5k text
textdata bss dec hex filename
492952 19571 13480 526003 806b3 net/built-in.o-with-metrics
487675 19275
60 matches
Mail list logo
