linux-kernel - Re: [patch 02/23] SLUB: Rename NUMA defrag_ratio to remote_node_defrag

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 8 Nov 2007 10:56:24 -0800 (PST)
From:	Christoph Lameter <clameter@....com>
To:	Mel Gorman <mel@...net.ie>
cc:	akpm@...ux-foundatin.org, linux-kernel@...r.kernel.org,
	linux-mm@...ck.org
Subject: Re: [patch 02/23] SLUB: Rename NUMA defrag_ratio to remote_node_defrag_ratio

On Thu, 8 Nov 2007, Mel Gorman wrote:

> On (06/11/07 17:11), Christoph Lameter didst pronounce:
> > We need the defrag ratio for the non NUMA situation now. The NUMA defrag works
> > by allocating objects from partial slabs on remote nodes. Rename it to
> > 
> > 	remote_node_defrag_ratio
> > 
> 
> I'm not too keen on the defrag name here largely because I cannot tell what
> it has to do with defragmention or ratios. It's really about working out
> when it is better to pack objects into a remote slab than reclaim objects
> from a local slab, right? It's also not clear what it is a ratio of what to
> what. I thought it might be clock cycles but that isn't very clear either.
> If we are renaming this can it be something like remote_packing_cost_limit ?

In a NUMA situation we have a choice between 

1. Allocating a page from the local node (which consumes more memory and 
is advantageous performance wise.

2. Not allocating from the local node but see if any other node has 
   available partially allocated slabs. If we allocate from them then
   we save memory and reduce the amount of partial slabs on the remote 
   node. Thus the fragmentation ratio is reduced.

> How about
> 
> /*
>  * When packing objects into slabs, it may become necessary to
>  * reclaim objects on a local slab or allocate from a remote node.
>  * The remote_packing_cost_limit is the maximum cost of remote
>  * accesses that should be paid before it becomes worthwhile to
>  * reclaim instead
>  */
> int remote_packing_cost_limit;
> 
> ?

That is not what this is about. And the functionality has been in SLUB 
since the beginning.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/