Messages in this thread | | | Date | Tue, 8 May 2007 18:32:35 -0700 (PDT) | From | Christoph Lameter <> | Subject | Re: + fix-spellings-of-slab-allocator-section-in-init-kconfig.patch added to -mm tree |
| |
On Tue, 8 May 2007, Matt Mackall wrote:
> On Tue, May 08, 2007 at 05:51:27PM -0700, Christoph Lameter wrote: > > On Tue, 8 May 2007, Matt Mackall wrote: > > > > > First, SLOB no longer runs on SMP because SLAB grew some RCU-related > > > hair. So it now effectively has no locks at all! > > > > Well it seems that SLOB was not well maintained. RCU has been around for a > > long time and SLOB has not been updated to cope with it. > > RCU's incursion into SLAB that broke SLOB is relatively new. And it > only broke for people using SMP or SPARSEMEM. Intersection with target > audience of SLOB: ~0.
New meaning in the last 3 years?
> > SLUB can put 32 objects sized 128 byte each in a 4k page. Can SLOB do > > the same? > > Yes. It can in fact put 512 8-byte objects in a 4k page. More
So can SLUB.
> importantly, it can put 2 1k objects and 16 128-byte objects on the > same page instead of on two pages.
That SLUB cannot do. And I do not believe you. SLOB must have some way to distinguish the objects and their sizes since kfree does not include size information. You can mix slabs of different size on the same page without metadata. Magic?
So how does kfree then know how to free the object? There must be some way where you get the metainformation. What is the point of your 8 byte metadata that keeps getting inserted? That does not consume memory on a page? - 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/
| |