![]() | |||||||||||||
Messages in this thread |
--"David S. Miller" <davem@davemloft.net> wrote (on Thursday, June 02, 2005 22:37:12 -0700): > From: "Martin J. Bligh" <mbligh@mbligh.org> > Date: Thu, 02 Jun 2005 22:34:42 -0700 > >> One of the calls I got the other day was for loopback interface. >> Default MTU is 16K, which seems to screw everything up and do higher >> order allocs. Turning it down to under 4K seemed to fix things. I'm >> fairly sure loopback doesn't really need phys contig memory, but it >> seems to use it at the moment ;-) > > It helps get better bandwidth to have larger buffers. > That's why AF_UNIX tries to use larger orders as well. Though surely the reality will be that after your system is up for a while, and is thorougly fragmented, your latency becomes frigging horrible for most allocs though? You risk writing a crapload of pages out to disk for every alloc ... > With all these processors using prefetching in their > memcpy() implementations, reducing the number of memcpy() > calls per byte is getting more and more important. > Each memcpy() call makes you hit the memory latency > cost since the first prefetch can't be done early > enough. but it's vastly different order of magnitude than touching disk. Can we not do a "sniff alloc" first (ie if this is easy, give it to me, else just fail and return w/o reclaim), then fall back to smaller allocs? Though I suspect the reality is that on any real system, a order 4 alloc will never actually succeed in any sensible amount of time anyway? Perhaps us lot just reboot too often ;-) M. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | ||||||||||||
| Last update: 2005-06-03 05:47 [from the cache] ©2003-2008 | |||||||||||||