[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Xen-devel] DMA trouble with current xen-sparse
On Fri, 2005-11-04 at 14:50 +0000, Ian Pratt wrote:
> > Sure, took a bit of time to recompile the kernel (I didn't do
> > this for years) and it crashed as expected, here are the info:
> > ptr: f160ed8e 1514
> > the size looks a full ethernet frame, i.e. 1500 of payload, 2
> > ethernet addresses and the 2bytes for the ethernet type, that
> > looks kosher to me but clearly it is not aligned.
> Please can you try using either our -xen or -xen0 kernel config. I
> strongly suspect there's something in your config that is breaking this
> for you, just not sure what.
I just tried to build it; it would not boot. That was building the
2.6.12 xen-sparse w/ gcc4; retrying with gcc32 now.
But I suspect that the problem is CONFIG_SLAB_DEBUG. That sets up slab
redzoning which checks for buffer overruns. One consequence is that
cached objects grow very slightly --- enough that the 2k kmalloc cache
gets created with 3 objects per order-2 slab, ie. all MTU-sized frames
are going to be allocated from an 8k slab and one in three will straddle
the page boundary.
I may not have time to verify that today, but it sounds like a likely
explanation for what we're seeing.
NB. even without redzoning, the slab allocator will try both order-1 and
order-2 slab sizes to see what minimises the wasted space in a slab, so
any subsystem that's doing its own allocation of objects from a pool
outside kmalloc may hit a size that creates these page-straddling
There's a hacky quick-fix, which is to change
#define BREAK_GFP_ORDER_HI 1
from 1 to 0 in mm/slab.c. But that's just going to waste more slab
cache space for many caches. Without that change, the fact is that an
important debugging option is creating cross-page objects routinely, and
that the slab allocator can create such objects quite normally even
without that option; so it may end up being something that Xen just has
to deal with.
Xen-devel mailing list