Umm ... could you provide some section headings for it?
size-4096 250 340 4096 65 85 1 : 340 1097 85 0 0 : 60 30 : 1298 179 727 7 637
is kind of hard to read ;-)
PS. zip attatched files are somewhat harder to read from Unix ;-)
--On Tuesday, October 08, 2002 4:52 PM -0700 "Kamble, Nitin A" <nitin.a.kamble@...> wrote:
> Attached is the /proc/slabinfo data on the 8 way ia64 cc-numa system (NEC
> AzusA); Running with the node aware slab allocator integrated into the atlas
> kernel. So it is running with the Erich's O(1) scheduler. The slabinfo
> snapshot is taken after a parallel kernel build.
> As you can see in the data, majority of the cache_free calls are from
> local nodes. There are few coming from remote nodes as well.
> In our code if the slab is not from local node, it can not go to the
> cpu_cache. Instead it is explicitly freed form the remote node.
> -----Original Message-----
> From: Martin J. Bligh [mailto:mbligh@...]
> Sent: Saturday, October 05, 2002 5:37 PM
> To: Manfred Spraul; Kamble, Nitin A; lse-tech@...
> Subject: Re: [Lse-tech] RE: node aware slab allocator for cc-numa
>> Could you send me a /proc/slabinfo output from a NUMA system with your
> patch applied, for an arbitrary stress test (dbench, kernel compile,
> whatever you use)?
>> Which percentage of the free calls are foreign?
>> I.e. what's the reason for accessing the kmem_cache_node_t structures?
>> Are the majority of the accesses from the local node, when it tries to
> refill/drain it's per-cpu array, or from remote nodes, when they return
> objects to the correct node?
>> If the majority is from remote nodes, then I don't see the reason for
> using per-node spinlocks and pointers for the node structure (+node local
> memory) in kmem_cache_t - just added complexity, without reducing cross-node
> memory traffic.
> That'll depend on what scheduler he uses as well, I suspect. I would
> hope the addition of a NUMA scheduler would help locality a lot, if
> you run just raw 2.4 without even O(1) sched, you results will
> probably be totally wacko ;-)