Re: [Lse-tech] Re: [RFC] Dynamic percpu data allocator

From: Mala Anand (manand@us.ibm.com)
Date: Thu May 30 2002 - 08:56:36 EST


                                                                                                                                               
                      dipankar@beaverton.ibm.co
                      m To: BALBIR SINGH <balbir.singh@wipro.com>
                      Sent by: cc: linux-kernel@vger.kernel.org, Rusty Russell <rusty@rustcorp.com.au>, Paul
                      lse-tech-admin@lists.sour McKenney/Beaverton/IBM@IBMUS, lse-tech@lists.sourceforge.net
                      ceforge.net Subject: [Lse-tech] Re: [RFC] Dynamic percpu data allocator
                                                                                                                                               
                                                                                                                                               
                      05/24/02 01:13 AM
                      Please respond to
                      dipankar
                                                                                                                                               
                                                                                                                                               

>On Fri, May 24, 2002 at 10:07:59AM +0530, BALBIR SINGH wrote:
>> Hello, Dipankar,
>>
>> I would prefer to use the existing slab allocator for this.
>> I am not sure if I understand your requirements for the per-cpu
>> allocator correctly, please correct me if I do not.
>>
>> What I would like to see
>>
>> 1. Have per-cpu slabs instead of per-cpu cpucache_t. One should
>> be able to tell for which caches we want per-cpu slabs. This
>> way we can make even kmalloc per-cpu. Since most of the kernel
>> would use and dispose memory before they migrate across cpus.
>> I think this would be useful, but again no data to back it up.

>Allocating cpu-local memory is a different issue altogether.
>Eventually for NUMA support, we will have to do such allocations
>that supports choosing memory closest to a group of CPUs.

>The per-cpu data allocator allocates one copy for *each* CPU.
>It uses the slab allocator underneath. Eventually, when/if we have
>per-cpu/numa-node slab allocation, the per-cpu data allocator
>can allocate every CPU's copy from memory closest to it.

Does this mean that memory allocation will happen in "each" CPU?
Do slab allocator allocate the memory in each cpu? Your per-cpu
data allocator sounds like the hot list skbs that are in the tcpip stack
in the sense it is one level above the slab allocator and the list is
kept per cpu. If slab allocator is fixed for per cpu, do you still
need this per-cpu data allocator?

_____________________________________________
Regards,
    Mala

   Mala Anand
   E-mail:manand@us.ibm.com
   Linux Technology Center - Performance
   Phone:838-8088; Tie-line:678-8088

-
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/



This archive was generated by hypermail 2b29 : Fri May 31 2002 - 22:00:28 EST