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
| ||
|
Date: Thu, 8 Nov 2007 20:10:47 +0000 From: mel@...net.ie (Mel Gorman) To: Christoph Lameter <clameter@....com> 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 (08/11/07 10:56), Christoph Lameter didst pronounce: > 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. > Ok, I get the logic somewhat now, thanks. > > 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. > Yeah, my understanding of SLUB is crap. Sorry for the noise. -- -- Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab - 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/
Powered by blists - more mailing lists