From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755501AbcANBYj (ORCPT ); Wed, 13 Jan 2016 20:24:39 -0500 Received: from mail-pa0-f48.google.com ([209.85.220.48]:35680 "EHLO mail-pa0-f48.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755182AbcANBYh (ORCPT ); Wed, 13 Jan 2016 20:24:37 -0500 Date: Wed, 13 Jan 2016 17:24:34 -0800 From: Alexei Starovoitov To: Ming Lei Cc: Martin KaFai Lau , Network Development , Linux Kernel Mailing List , FB Kernel Team Subject: Re: [PATCH v2 net-next 3/4] bpf: bpf_htab: Add syscall to iterate percpu value of a key Message-ID: <20160114012433.GB43324@ast-mbp.thefacebook.com> References: <1452586852-1575604-1-git-send-email-kafai@fb.com> <1452586852-1575604-4-git-send-email-kafai@fb.com> <20160113052341.GB37858@ast-mbp.thefacebook.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jan 13, 2016 at 11:43:50PM +0800, Ming Lei wrote: > On Wed, Jan 13, 2016 at 1:23 PM, Alexei Starovoitov > wrote: > > On Wed, Jan 13, 2016 at 10:42:49AM +0800, Ming Lei wrote: > >> > >> So I don't think it is good to retrieve value from one CPU via one > >> single system call, and accumulate them finally in userspace. > >> > >> One approach I thought of is to define the function(or sort of) > >> > >> handle_cpu_value(u32 cpu, void *val_cpu, void *val_total) > >> > >> in bpf kernel code for collecting value from each cpu and > >> accumulating them into 'val_total', and most of situations, the > >> function can be implemented without loop most of situations. > >> kernel can call this function directly, and the total value can be > >> return to userspace by one single syscall. > >> > >> Alexei and anyone, could you comment on this draft idea for > >> perpcu map? > > > > I'm not sure how you expect user space to specify such callback. > > Kernel cannot execute user code. > > I mean the above callback function can be built into bpf code and then > run from kernel after loading like in packet filter case by tcpdump, maybe > one new prog type is needed. It is doable in theroy. I need to investigate > a bit to understand how it can be called from kernel, and it might be OK > to call it via kprobe, but not elegent just for accumulating value from each > CPU. that would be a total overkill. > > Also syscall/malloc/etc is a noise comparing to ipi and it > > will still be there, so > > for(all cpus) { syscall+ipi;} will have the same speed. > > In the syscall path, lots of slow things, and finally the accumulated > value is often stale and may not reprensent accurate number at any > time, and can be thought as invalid. no. stale != invalid. Some analytics/monitor applications are good with ball park numbers and for them regular hash map with non-atomic increment is good enough, but others need accurate numbers. Even though they may be seconds stale.