Messages in this thread | | | Date | Wed, 6 Sep 2006 10:35:55 +0800 | From | Aubrey <> | Subject | Re: 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.
-Aubrey
On 9/5/06, David Howells <dhowells@redhat.com> wrote: > Aubrey <aubreylee@gmail.com> 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 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/
| |