Messages in this thread | | | Date | Wed, 26 Aug 2015 20:00:05 +0530 | From | Raghavendra K T <> | Subject | Re: [PATCH RFC 0/2] Optimize the snmp stat aggregation for large cpus |
| |
On 08/26/2015 07:39 PM, Eric Dumazet wrote: > 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.kt@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.
Okay. Another problem I thought here was that we could only loop over online cpus.
>>> 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. >
Okay. I 'll send V2 with declaring tmp buffer in stack.
| |