![]() | |||||||||||||
Messages in this thread |
Dipankar Sarma wrote: > > On Thu, Dec 05, 2002 at 09:10:16PM +0100, Andrew Morton wrote: > > > > I'd suggest that you drop the new allocator until a compelling > > need for it (in real, live 2.5/2.6 code) has been demonstrated. > > Fine with me since atleast one workaround for fragmentation with small > allocations is known. I can't see anything in 2.5 timeframe > requiring small per-cpu allocations. > > Would you like me to resubmit a simple kmalloc-only version ? > I think that would be best. BTW, looking at the snmp application of this work: +#define ICMP_INC_STATS_USER_FIELD(offt) \ + (*((unsigned long *) ((void *) \ + per_cpu_ptr(icmp_statistics[1], \ + smp_processor_id())) + offt))++; This guy is racy on preempt. Just a little bit. It is effectively: ptr = per_cpu_ptr(...); (*ptr)++; On some architectures, `(*ptr)++' is not atomic wrt interrupts. The CPU could be preempted midway through the increment. Surely it's not an issue for SNMP stats, but for some applications such as struct page_state, such a permanent off-by-a-little-bit would be a showstopper. So some big loud comments which describe the worthiness of get_cpu_ptr(), and the potential inaccuracy of per_cpu_ptr would be useful. And as this is the first application of the kmalloc_precpu infrastructure, it may be best to convert it to use get_cpu_ptr/put_cpu_ptr. - 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 12:31 [W:0.259 / U:0.240 seconds] ©2003-2008 Jasper Spaans | |||||||||||||