linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Mikulas Patocka <mpatocka@redhat.com>
To: David Rientjes <rientjes@google.com>
Cc: Ingo Molnar <mingo@redhat.com>, linux-mm@kvack.org
Subject: Re: [PATCH] mempool: add unlikely and likely hints
Date: Fri, 7 Mar 2014 16:15:13 -0500 (EST)	[thread overview]
Message-ID: <alpine.LRH.2.02.1403071557060.894@file01.intranet.prod.int.rdu2.redhat.com> (raw)
In-Reply-To: <alpine.DEB.2.02.1403071254220.23969@chino.kir.corp.google.com>



On Fri, 7 Mar 2014, David Rientjes wrote:

> On Fri, 7 Mar 2014, Mikulas Patocka wrote:
> 
> > > What observable performance benefit have you seen with this patch and 
> > > with what architecture?  Could we include some data in the changelog?
> > 
> > None - you usually don't get observable performance benefit from 
> > microoptimizations like this.
> > 
> > It may be that the cache line that the patch saves aliases some other 
> > important cache lines and then, the patch saves two cache line refills. 
> > Or, the saved cache line doesn't alias anything important and then the 
> > patch doesn't have any effect at all. It's not worth spending many days or 
> > weeks trying to recreate a situation when the code cache is used in such a 
> > way that the patch would help.
> 
> Not sure there's any benefit of merging the patch, then.

That's right, no one can be sure. The patch maybe helps and maybe has no 
effect (it can't hurt) - so there is no reason not to merge it.

If you measured the effect of microoptimizations like this, you spend 
excessive amount of time doing it and in the end you either improve 
performance a little bit or not. If you apply the patch blindly without 
measuring, you either improve performance a little bit or not. So - trying 
to prove that it helps doesn't have any positive effect at all.

If the patch could hurt performance, it would be reasonable to do some 
measurement to prove that it doesn't. But this one can't hurt.

Mikulas

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

      reply	other threads:[~2014-03-07 21:15 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-06 22:15 Mikulas Patocka
2014-03-07 10:10 ` David Rientjes
2014-03-07 14:50   ` Mikulas Patocka
2014-03-07 20:54     ` David Rientjes
2014-03-07 21:15       ` Mikulas Patocka [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.LRH.2.02.1403071557060.894@file01.intranet.prod.int.rdu2.redhat.com \
    --to=mpatocka@redhat.com \
    --cc=linux-mm@kvack.org \
    --cc=mingo@redhat.com \
    --cc=rientjes@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox