Re: Avoiding external fragmentation with a placement policy Version 12

["Martin J. Bligh" <mbligh@mbligh.org>]

--"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/