[lkml]   [2006]   [Sep]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: kernel BUGs when removing largish files with the SLOB allocator
Yeah, I agree with most of your opinion. Using PG_slab is really a
quickest way to determine the size of the object. But I think using a
flag named "PG_slab" on a memory algorithm named "slob" seems not
reasonable. It may confuse the people who start to read the kernel
source code. So I'm writing to ask if there is a better solution to
fix the issue.


On 9/5/06, David Howells <> wrote:
> Aubrey <> wrote:
> > IMHO the problem is nommu.c is written for slab only. So when slob is
> > enabled, it need to be considered to make some modification to make
> > two or more memory allocator algorithms work properly, rather than to
> > force all others algorithm to be compatible with the current one(slab)
> > to match the code in the nommu.c, which is not common enough.
> >
> > Does that make sense?
> No, not really.
> The point is that kobjsize() needs to determine the size of the object it has
> been asked to assess. It knows how to do that directly if the page is
> allocated by the main page allocator, but not if the page belongs to the slab
> allocator. The quickest way it can determine this is to look at PG_slab. In
> such a case it defers to the slab allocator for a determination.
> What I don't want to happen is that we have to defer immediately to the slob
> allocator which then goes and searches various lists to see if it owns the
> page. Remember: unless the page is _marked_ as belonging to the slob
> allocator, the slob allocator may _not_ assume any of the metadata in struct
> page is valid slob metadata. It _has_ to determine the validity of the page
> by other means _before_ it can use the metadata, and that most likely means a
> search. This is why PG_slab exists: if it is set, you _know_ you can
> instantly trust the metadata.
> Since slob appears to be an entry-point-by-entry-point replacement for the
> slab allocator, the slob allocator can also mark its pages for anything that's
> looking to defer to it using PG_slab since the presence of slab and slob are
> mutually exclusive.
> Also, we already have two major memory allocator algorithms in the kernel at
> any one time: (1) the main page allocator and (2) slab or slob. We don't
> really want to start going to three or more.
> So, I come back to the main question: Why don't you want to use PG_slab?
> David
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2006-09-06 04:41    [W:0.068 / U:1.448 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site