Messages in this thread | | | Date | Fri, 03 Jun 2005 16:43:45 +1000 | From | Nick Piggin <> | Subject | Re: Avoiding external fragmentation with a placement policy Version 12 |
| |
Martin J. Bligh wrote: >>>It would really help your cause in the short term if you can >>>demonstrate improvements for say order-3 allocations (eg. use >>>gige networking, TSO, jumbo frames, etc). >> >>TSO chops up the user data into PAGE_SIZE chunks, it doesn't >>make use of non-zero page orders. >>
My mistake. Thanks for correcting me.
> 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 ;-) >
Out of interest, I did do some tests a while back that showed 16K is good for TCP over loopback bandwidth on a few different types of CPUs (P3, Xeon, Opteron...).
IIRC 32K may have been slightly faster, but not enough to warrant that size allocation.
Bandwidth for smaller sizes dropped off quite significantly, although I'm not sure if that would have been from the actual memory copy overhead or increased per-'something' overhead in the network code. If the latter, that would suggest at least in theory it could use noncongiguous physical pages.
> >>Actually, even with TSO enabled, you'll get large order >>allocations, but for receive packets, and these allocations >>happen in software interrupt context. > > > Sounds like we still need to cope then ... ? >
Sure. Although we should try to not use higher order allocs if possible of course. Even with a fallback mode, you will still be putting more pressure on higher order areas and thus degrading the service for *other* allocators, so such schemes should obviously be justified by performance improvements.
-- SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com
- 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/
| |