[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Xen-devel] DMA trouble with current xen-sparse



Hi,

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
caches.  

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.

--Stephen



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.