Messages in this thread | | | Date | Thu, 02 Jun 2005 22:42:52 -0700 | From | "Martin J. Bligh" <> | Subject | Re: Avoiding external fragmentation with a placement policy Version 12 |
| |
--"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/
| |