lkml.org 
[lkml]   [2001]   [Dec]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [Lse-tech] [RFC] [PATCH] Scalable Statistics Counters
I think Jack got his attribution wrong.  Which is good for me,
since I wrote what Jack just gently demolished <grin>.


On Sat, 8 Dec 2001, Jack Steiner wrote:

> I think it depends on whether the slab allocator manages
> memory by cpu or node. Since the number of cpus per node
> is rather small (<=8) for most NUMA systems, I would expect
> the slab allocator to manage by node. Managing by cpu would
> likely add extra fragmentation and no real performance benefit.

I wasn't intending to suggest that the slab allocator manage by
cpu, rather than by node. Pretty clearly, that would be silly.
Rather I was doing two things:

1) Suggesting that if some code asking for memory wanted
it on a node near to some cpu, that it not convert that
cpu to a node _before_ the call, but rather, pass in the
cpu, and let the called routine, kmem_cache_alloc_node()
or renamed to kmem_cache_alloc_cpu() map the cpu to the
node, inside the call.

2) Suggesting (against common usage in the kernel, as Jack
describes, so probably I'm tilting at wind mills) that
we distinguish between nodes and and chunks of memory
that I've started calling memory blocks.

I think (1) is sensible enough - the entire discussion leading
up to the code example involved getting memory near to some
cpu or other - so let the call state just that, and let the
details of translating to whatever units the slab allocator
works with be handled inside the call. Don't make each
caller remember to perform a CPU_TO_NODE conversion - it's
just a little silly duplication of code (a kernel a few
bytes larger), a slightly less direct interface, and one
more detail to impose on each person coding such a call.

As to (2) I'd have to get Jack in a room with a white board, and
at this point, I'm placing no bets on what we would conclude
(well, actually I'd bet on Jack if forced ... his batting
average is pretty good ;).


I won't rest till it's the best ...
Manager, Linux Scalability
Paul Jackson <pj@sgi.com> 1.650.933.1373

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:13    [W:0.056 / U:4.472 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site