lkml.org 
[lkml]   [2002]   [Dec]   [5]   [last100]   RSS-feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
Complete thread (EXPERIMENTAL)
/
DateThu, 5 Dec 2002 16:23:29 +0530
FromDipankar Sarma <>
SubjectRe: [patch] kmalloc_percpu -- 2 of 2
Digg This
Hi Andrew,

On Wed, Dec 04, 2002 at 08:32:58PM -0800, Andrew Morton wrote:
Where in the kernel is such a large number of 4-, 8- or 16-byte objects being used?

Well, kernel objects may not be that small, but one would expect the per-cpu parts of the kernel objects to be sometimes small, often down to a couple of counters counting statistics.


The slab allocator will support caches right down to 1024 x 4-byte objects per page. Why is that not appropriate?

Well, if you allocated 4-byte objects directly from the slab allocator, you aren't guranteed to *not* share a cache line with another object modified by a different cpu.


Sorry, but you have what is basically a brand new allocator in there, and we need a very good reason for including it. I'd like to know what that reason is, please.

The reason is concern about per-cpu allocation for small per-CPU parts (typically counters) of objects. If a driver has two counters counting reads and writes, you don't want to eat up a whole cacheline for them for each CPU per instance of the device.

Thanks
-- 
Dipankar Sarma  <dipankar@in.ibm.com> http://lse.sourceforge.net
Linux Technology Center, IBM Software Lab, Bangalore, India.
\
ISP Services
Valid XHTML 1.0!\ /
Valid CSS! Last update: 2005-03-22 12:31    [W:9.184 / U:0.000 seconds]
©2003-2005 Jasper Spaans