From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754859Ab1ACNp4 (ORCPT ); Mon, 3 Jan 2011 08:45:56 -0500 Received: from hrndva-omtalb.mail.rr.com ([71.74.56.124]:64251 "EHLO hrndva-omtalb.mail.rr.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754762Ab1ACNpz (ORCPT ); Mon, 3 Jan 2011 08:45:55 -0500 X-Authority-Analysis: v=1.1 cv=UQuFHoD2CPQ248x8AXEbKhr4z9AaDqApxmEl3BhfZ64= c=1 sm=0 a=4pdSCqo9-bIA:10 a=Q9fys5e9bTEA:10 a=OPBmh+XkhLl+Enan7BmTLg==:17 a=pGLkceISAAAA:8 a=TSbVqHtbAAAA:8 a=BC2e34ar1K9Vy1x282oA:9 a=4nncSqCRAbj-uf8OCgkA:7 a=EL7hyAKsZmKzTpVvSXKAqbb_uikA:4 a=PUjeQqilurYA:10 a=MSl-tDqOz04A:10 a=OPBmh+XkhLl+Enan7BmTLg==:117 X-Cloudmark-Score: 0 X-Originating-IP: 67.242.120.143 Subject: Re: Should we be using unlikely() around tests of GFP_ZERO? From: Steven Rostedt To: Pekka Enberg Cc: Minchan Kim , "Theodore Ts'o" , Christoph Lameter , Pekka Enberg , Matt Mackall , linux-mm@kvack.org, linux-kernel@vger.kernel.org, David Rientjes , npiggin@kernel.dk In-Reply-To: References: Content-Type: text/plain; charset="ISO-8859-15" Date: Mon, 03 Jan 2011 08:45:51 -0500 Message-ID: <1294062351.3948.7.camel@gandalf.stny.rr.com> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 2011-01-03 at 09:40 +0200, Pekka Enberg wrote: > Hi, > > On Mon, Jan 3, 2011 at 8:48 AM, Theodore Ts'o wrote: > >> Given the patches being busily submitted by trivial patch submitters to > >> make use kmem_cache_zalloc(), et. al, I believe we should remove the > >> unlikely() tests around the (gfp_flags & __GFP_ZERO) tests, such as: > >> > >> - if (unlikely((flags & __GFP_ZERO) && objp)) > >> + if ((flags & __GFP_ZERO) && objp) > >> memset(objp, 0, obj_size(cachep)); > >> > >> Agreed? If so, I'll send a patch... > > On Mon, Jan 3, 2011 at 5:46 AM, Minchan Kim wrote: > > I support it. > > I guess the rationale here is that if you're going to take the hit of > memset() you can take the hit of unlikely() as well. We're optimizing > for hot call-sites that allocate a small amount of memory and > initialize everything themselves. That said, I don't think the > unlikely() annotation matters much either way and am for removing it > unless people object to that. > > On Mon, Jan 3, 2011 at 5:46 AM, Minchan Kim wrote: > > Recently Steven tried to gather the information. > > http://thread.gmane.org/gmane.linux.kernel/1072767 > > Maybe he might have a number for that. > > That would be interesting, sure. Note, you could do it yourself too. Just enable: Kernel Hacking -> Tracers -> Branch Profiling (Trace likely/unlikely profiler) CONFIG_PROFILE_ANNOTATED_BRANCHES Then search /debug/tracing/trace_stats/branch_annotated. (hmm, the help in Kconfig is wrong, I need to fix that) Anyway, here's my box. I just started it an hour ago, and have not been doing too much on it yet. But here's what I got (using SLUB) correct incorrect % Function File Line ------- --------- - -------- ---- ---- 6890998 2784830 28 slab_alloc slub.c 1719 That's incorrect 28% of the time. -- Steve