Re: [patch 00/23] Slab defragmentation V6
- From: Christoph Lameter <clameter@xxxxxxx>
- Date: Thu, 8 Nov 2007 11:12:48 -0800 (PST)
On Thu, 8 Nov 2007, Mel Gorman wrote:
On Tue, 2007-11-06 at 17:11 -0800, Christoph Lameter wrote:
Slab defragmentation is mainly an issue if Linux is used as a fileserver
Was hoping this would get renamed to SLUB Targetted Reclaim from
discussions at VM Summit. As no copying is taking place, it's confusing
to call it defragmentation to me anyway. Not a major deal but it made
reading the patches a little confusing.
The problem is that people are focusing on one feature here and forget
about the rest. Targetted reclaim is one feature that was added later when
lumpy reclaim was added to the kernel. The primary intend of this patchset
was always to reduce the fragmentation. The name is appropriate and the
patchset will support copying of objects as soon as support for that is
added to the kick(). In that case the copying you are looking for will be
there. The simple implementation for the kick() methods is to simply copy
pieces of the reclaim code. That is what is included here.
With lumpy reclaim slab defragmentation can be used to enhance the
ability to recover larger contiguous areas of memory. Lumpy reclaim currently
cannot do anything if a slab page is encountered. With slab defragmentation
that slab page can be removed and a large contiguous page freed. It may
be possible to have slab pages also part of ZONE_MOVABLE (Mel's defrag
scheme in 2.6.23)
More terminology nit-pick - ZONE_MOVABLE is not defragmenting anything.
It's just partitioning memory. The slab pages need to be 100%
reclaimable or movable for that to happen but even with targetted
reclaim, some dentries such as the root directory one cannot be
reclaimed, right?
100%? I am so fond of these categorical statements ....
ZONE_MOVABLE also contains mlocked pages that are also not reclaimable.
The question is at what level would it be possible to make them MOVABLE?
It may take some improvements to the kick() methods to make eviction more
reliable. Allowing the moving of objects in the kick() methods will
likely get usthere.
It'd still be valid to leave them as MIGRATE_RECLAIMABLE because that is
what they are. Arguably, MIGRATE_RECLAIMABLE could be dropped in it's
entirety but I'd rather not as reclaimable blocks have significantly
different reclaim costs to pages that are currently marked movable.
Right. That would simplify the antifrag methods. Is there any way to
measure the reclaim costs?
V5->V6
- Rediff against 2.6.24-rc2 + mm slub patches.
- Add reviewed by lines.
- Take out the experimental code to make slab pages movable. That
has to wait until this has been considered by Mel.
I still haven't considered them properly. I've been backlogged for I
don't know how long at this point and this is on the increasingly large
todo list :( . I don't believe it is massively urgent at the moment
though and reclaiming to start with is perfectly adequate just as lumpy
reclaim is fine at the moment.
Right. We can defer this for now.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
- Follow-Ups:
- Re: [patch 00/23] Slab defragmentation V6
- From: Lee Schermerhorn
- Re: [patch 00/23] Slab defragmentation V6
- From: Mel Gorman
- Re: [patch 00/23] Slab defragmentation V6
- References:
- [patch 00/23] Slab defragmentation V6
- From: Christoph Lameter
- Re: [patch 00/23] Slab defragmentation V6
- From: Mel Gorman
- [patch 00/23] Slab defragmentation V6
- Prev by Date: Re: [PATCH 0/6] MN10300: Add the MN10300 architecture to Linux kernel [try #4]
- Next by Date: How do I debug PCI resource allocation problems
- Previous by thread: Re: Plans for Onezonelist patch series ???
- Next by thread: Re: [patch 00/23] Slab defragmentation V6
- Index(es):
Relevant Pages
|