| |||||||||||||
Large pages, large blocks, and large problemsLarge pages, large blocks, and large problemsPosted Sep 20, 2007 0:49 UTC (Thu) by drag (subscriber, #31333)In reply to: Large pages, large blocks, and large problems by socket Parent article: Large pages, large blocks, and large problems
> And otherwise, I'm curious how the proposed changes would affect the work of people who are trying to get Linux to scale down to smaller devices?
I donno. All of this stuff is over my head, but I expect it would either have a generally null effect to generally positive effect.
I know that a popular task to put Linux to use for is those little embedded 'NAS' controllers. You know, those things running little ARM proccessor or something lightweight like that were you can shove 3 or 4 SATA drives into and they cost around 100-200 bucks or so.
I know that for Gigabit speed networks, and faster interconnects, one of the major problems you have, in terms of performance, is that they are still using very tiny MTU's originally developed for 10Mbit/s networks. 'Jumbo frames' are were you take the small 1500 bytes and bump the size up to 9500bytes or even higher. This leads to significantly less interrupts being generated by the controller and much less TCP overhead. IF all your hardware and network hardware supports it. You can realy get very significant network performance improvements. Sometimes 2x the performance at half the cpu usage.
Then if you take that further and are able to use large packets with large disk blocks, say that if you strip away the ethernet frame and tcp information the datagram of the packet and the size of the disk block is the same size, then I suppose you can reduce overhead and increase performance even more.
All in all this would allow people to make slower/cheaper proccessors and perform better. Cheaper, faster embedded Linux devices.
Of course this is all very idealized. Lots of switches and NICs don't support jumbo packets, most people will still use Widnows with SMB which is just naturally slow, and most people don't have the abilty to configure the network in this way even if they know how. Plus the sorts of CPU they use I don't know if they would even have those large memory page sizes supported.
Oh well.
> Can someone recommend reading materials (preferably free, but don't rule something really good out just on that account) on this stuff?
Ever checked out http://kernelnewbies.org/
(Log in to post comments)
Large pages, large blocks, and large problems Posted Sep 20, 2007 1:58 UTC (Thu) by sayler (guest, #3164) [Link] In general, I agree with what you say, but keep in mind that Ethernet frames are inherently variable in size, that is, you can have 1500, 1501, 1502, ... byte frames and the transmission time will increase nearly linearly.
We have much coarser choices for page sizes. Even on Alpha (which apparently did a good job here), page size choices were something like 8k ** 2*N where N ran between 0 and 3..
There is some other somewhat interesting data here: http://lists.freebsd.org/pipermail/freebsd-hackers/2003-O... showing measured {i,d}tlb size for various page sizes on various uArchs.
Large pages, large blocks, and large problems Posted Sep 21, 2007 15:16 UTC (Fri) by jamesh (guest, #1159) [Link] It is true that ethernet frames are variable size, but it also states that the maximum payload size is 1500 bytes as the grandparent post says. You need to have some upper limit in order to make hardware that can reliably store and forward packets (as a switch would need to do when forwarding a packet to a slower network).
Ethernet frames larger than 1500 bytes are non-standard and commonly known as "jumbo frames". And as you can guess, they'll only work if all the hardware involved in the link supports the larger frames.
|
|||||||||||||