Weekly Edition
Return to the Kernel page
| |||||||||||||
Quotes of the week
Modern network hardware has often sprouted various "offload"
engines, unfortunately now often enabled by default, which tend to
do more damage than good except for extreme benchmarking fanatics,
often primarily on big server machines in data centers. Start by
turning them off. We'll write more on this topic soon. The
implementors of this "smart" hardware are less "smart" than they
think they are.
— The
Bufferbloat project on CoDel benchmarking best practices
When we enter the kernel mode, we start with saving CPU state.
Usually (and you are going to hate that word well before you read
to the end) it's stored in struct pt_regs, but it might be more
complicated. For our purposes it's better to think of it as
abstract saved state, leaving aside the question of how it's
represented.
— Al Viro teaches a class on signal
handling(Log in to post comments)
Quotes of the week Posted Dec 13, 2012 16:22 UTC (Thu) by BenHutchings (subscriber, #37955) [Link] Modern network hardware has often sprouted various "offload" engines, unfortunately now often enabled by default, ... Start by turning them off. Yes, I really hate the bloat introduced by checksum offload, what a terrible idea that was! Seriously, I suspect the writer is mostly thinking of TSO, which is supported and enabled on most Ethernet hardware but only applied as requested by the kernel. It is up to the TCP implementation, not the hardware, to decide how it is used. (Some hardware (particularly 10G) also has LRO, and that does introduce buffering in hardware outside of the kernel's control.) The implementors of this "smart" hardware are less "smart" than they think they are. The writer of this document is less helpful than he thinks he is.
Quotes of the week Posted Dec 13, 2012 20:31 UTC (Thu) by intgr (subscriber, #39733) [Link]
Agreed. Bufferbloat might be an important problem, but it really bothers me how the bufferbloat crowd seems to think it's the only problem that needs to be solved in computing.
By reducing buffering, you make the CPU wake up more frequently, thus consume more power. By disabling TSO, you make the CPU do more work to transmit the same amount of data.
They should be looking for the sweet spot between power efficiency, CPU load and latency, but I have never seen that kind of thinking in any of their public communication.
I also haven't seen any reasoning for why they're dismissing delay-based congestion control algorithms like TCP Vegas, which can inherently detect bufferbloat and scale back before filling the buffers.
Quotes of the week Posted Dec 13, 2012 22:37 UTC (Thu) by samlh (subscriber, #56788) [Link]
> They should be looking for the sweet spot between power efficiency, CPU load and latency, but I have never seen that kind of thinking in any of their public communication.
All of the benchmarks I have seen from them validating various techniques also measure bandwidth as well. While they are focused on one particular problem, I feel they do care about not breaking things in the process.
> I also haven't seen any reasoning for why they're dismissing delay-based congestion control algorithms like TCP Vegas, which can inherently detect bufferbloat and scale back before filling the buffers.
That only works if every stream is using Vegas - otherwise, the Vegas streams will be penalized against the other streams. For inherently background stuff, this is ok; indeed, uTP for bittorrent works on this principle. However, for everything else it is not a viable option.
|
|||||||||||||