On Tue, 26 Jun 2007, Nish Aravamudan wrote:
> >kmem_cache_defrag takes a node parameter. This can either be -1 if
> >defragmentation should be performed on all nodes, or a node number.
> >If a node number was specified then defragmentation is only performed
> >on a specific node.
>
On 6/18/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Slab defragmentation occurs either
1. Unconditionally when kmem_cache_shrink is called on slab by the kernel
calling kmem_cache_shrink or slabinfo triggering slab shrinking. This
form performs defragmentation on all nodes of a NUMA s
On Tue, 26 Jun 2007, Andrew Morton wrote:
> Damned if I know. Perhaps by reading slob.c instead of slub.c. When can
> we start deleting some slab implementations?
Probably after we switch to SLUB in 2.6.23 and then address all the
eventual complaints and issues that come up.
> > See http://ma
On Tue, 26 Jun 2007 11:19:26 -0700 (PDT)
Christoph Lameter <[EMAIL PROTECTED]> wrote:
>
> > But slab_lock() isn't taken for slabs whose objects are larger than
> > PAGE_SIZE. How's that handled?
>
> slab lock is always taken. How did you get that idea?
Damned if I know. Perhaps by reading sl
On Tue, 26 Jun 2007, Andrew Morton wrote:
> > No slab operations may be performed in get_reference(). Interrupts
>
> s/get_reference/get/, yes?
Correct.
> (What's the smallest sized object slub will create? 4 bytes?)
__alignof__(unsigned long long)
> To hold off a concurrent free while d
On Mon, 18 Jun 2007 02:58:50 -0700 [EMAIL PROTECTED] wrote:
> Slab defragmentation occurs either
>
> 1. Unconditionally when kmem_cache_shrink is called on slab by the kernel
>calling kmem_cache_shrink or slabinfo triggering slab shrinking. This
>form performs defragmentation on all nodes
6 matches
Mail list logo
