[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.64.0709171420330.29704@schroedinger.engr.sgi.com>
Date: Mon, 17 Sep 2007 14:23:05 -0700 (PDT)
From: Christoph Lameter <clameter@....com>
To: Lee Schermerhorn <Lee.Schermerhorn@...com>
cc: linux-kernel <linux-kernel@...r.kernel.org>,
akpm@...ux-foundation.org, ak@...e.de, eric.whitney@...com,
Mel Gorman <mel@....ul.ie>
Subject: Re: [PATCH] 2.6.23-rc6: Fix NUMA Memory Policy Reference Counting
On Mon, 17 Sep 2007, Lee Schermerhorn wrote:
> Only for vma policy, right? show_numa_maps() isn't a performance path,
> and shared policies are already reference counted--just not unref'd!
Right.
> I do have some ideas for enhancements to memtoy to test vma policies in
> a multi-threaded task. I have the basic multi-threading infrastructure
> that binds threads to cpus, allocates node local stacks, thread state
> structs, ... in my mmtrace tool that I can probably hack for use in
> memtoy to provoke cacheline bouncing of the mem policy. But, if pft
> does the trick, I won't rush the memtoy enhancments...
Well pft is old and limited in what it can do. I'd be glad if you could
put it into memtoy. Then it may perhaps be useful in the future.
> Meanwhile, we do have a mem policy ref counting bug in the mainline.
But we have had this ref counting issue forever with no ill effect. Memory
policies were designed to have almost no overhead for the default
allocation paths. Incrementing and decrementing refcounters makes that
design no longer light weight as it was intended to be.
-
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