Messages in this thread | | | Date | Fri, 29 Jun 2007 14:04:15 +0100 (BST) | From | Hugh Dickins <> | Subject | Re: [PATCH] Containment measures for slab objects on scatter gather lists |
| |
On Thu, 28 Jun 2007, Christoph Lameter wrote:
> I had a talk with James Bottomley last night and it seems that there is an > established way of using the page structs of slab objects in the block > layer. Drivers may use the DMA interfaces to issue control commands. In > that case they may allocate a short structure via the slab allocator and > put the control commands into that slab object. > > The driver will then perform a sg_init_one() on the slab object. > sg_init_one() calls sg_set_buf() which determines the page struct of a > page. In this case sg_set_buf() will determine the page struct of a slab > object. The dma layer may then perform operations on the "slab page". The > block layer folks seem to have spend some time to make this work right.
Yes, I don't see why this comes as such a surprise and horror to you, so much in need of dire WARNINGs. kmalloc memory is not a different kind of memory from what you get from the page allocators.
I stand by my page_mapping patch, and the remark I made before, that page_mapping(page) is the correct place to check this. What is page_mapping(page) for? Precisely to return the struct address_space* from page->mapping when that's what's in there, and not when that field has been reused for something else.
So lines like > + mapping = PageSlab(page) ? NULL : page_mapping(page); seem to miss the point.
I agree that the only clash found yet has been in flush_dcache_page, so some bytes and branches can indeed be saved by just doing the test in there. Oh, but your VM_BUG_ON cancels out that saving. And if we were to try to save bytes and branches there, it's the synthetic swapper_space business (only required in a couple of places) I'd be wanting to cut out.
To me this all seems like a big fuss to excuse your surprise: so please don't expect an Ack from me; but if others prefer this, I won't be Nacking. (Though I'll probably whine about it into eternity ;)
Hugh - 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/
| |