On Wed, 2015-08-26 at 15:55 +0530, Raghavendra K T wrote: > On 08/26/2015 04:37 AM, David Miller wrote: > > From: Raghavendra K T <raghavendra...@linux.vnet.ibm.com> > > Date: Tue, 25 Aug 2015 13:24:24 +0530 > > > >> Please let me know if you have suggestions/comments. > > > > Like Eric Dumazet said the idea is good but needs some adjustments. > > > > You might want to see whether a per-cpu work buffer works for this. > > sure, Let me know if I understood correctly, > > we allocate the temp buffer, > we will have a "add_this_cpu_data" function and do > > for_each_online_cpu(cpu) > smp_call_function_single(cpu, add_this_cpu_data, buffer, 1) > > if not could you please point to an example you had in mind.
Sorry I do not think it is a good idea. Sending an IPI is way more expensive and intrusive than reading 4 or 5 cache lines from memory (per cpu) Definitely not something we want. > > > > > It's extremely unfortunately that we can't depend upon the destination > > buffer being properly aligned, because we wouldn't need a temporary > > scratch area if it were aligned properly. > > True, But I think for 64 bit cpus when (pad == 0) we can go ahead and > use stats array directly and get rid of put_unaligned(). is it correct? Nope. We have no alignment guarantee. It could be 0x............04 pointer value. (ie not a multiple of 8) > > (my internal initial patch had this version but thought it is ugly to > have ifdef BITS_PER_LONG==64) This has nothing to do with arch having 64bit per long. It is about alignment of a u64. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
