linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "H. Peter Anvin" <hpa@zytor.com>
To: Chris Wilson <chris@chris-wilson.co.uk>,
	Andy Lutomirski <luto@amacapital.net>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Ross Zwisler <ross.zwisler@linux.intel.com>,
	"H . Peter Anvin" <hpa@linux.intel.com>,
	Borislav Petkov <bp@alien8.de>, Brian Gerst <brgerst@gmail.com>,
	Denys Vlasenko <dvlasenk@redhat.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Imre Deak <imre.deak@intel.com>,
	Daniel Vetter <daniel.vetter@ffwll.ch>,
	DRI <dri-devel@lists.freedesktop.org>
Subject: Re: [PATCH] x86: Add an explicit barrier() to clflushopt()
Date: Thu, 7 Jan 2016 14:29:58 -0800	[thread overview]
Message-ID: <568EE6E6.4000904@zytor.com> (raw)
In-Reply-To: <20160107215401.GB25144@nuc-i3427.alporthouse.com>

On 01/07/16 13:54, Chris Wilson wrote:
> 
> Whilst you are looking at this asm, note that we reload
> boot_cpu_data.x86_cflush_size everytime around the loop. That's a small
> but noticeable extra cost (especially when we are only flushing a single
> cacheline).
> 

I did notice that; I don't know if this is a compiler failure to do an
obvious hoisting (which should then be merged with the other load) or a
consequence of the volatile.  It might be useful to report this to the
gcc bugzilla to let them look at it.

Either way, the diff looks good and you can add my:

Acked-by: H. Peter Anvin <hpa@linux.intel.com>

However, I see absolutely nothing wrong with the assembly other than
minor optimization possibilities: since gcc generates an early-out test
as well as a late-out test anyway, we could add an explicit:

	if (p < vend)
		return;

before the first mb() at no additional cost (assuming gcc is smart
enough to skip the second test; otherwise that can easily be done
manually by replacing the for loop with a do { } while loop.

I would be very interested in knowing if replacing the final clflushopt
with a clflush would resolve your problems (in which case the last mb()
shouldn't be necessary either.)

Something like:

void clflush_cache_range(void *vaddr, unsigned int size)
{
	unsigned long clflush_size = boot_cpu_data.x86_clflush_size;
	char *vend = (char *)vaddr + size;
	char *p = (char *)((unsigned long)vaddr & ~(clflush_size - 1);

	if (p >= vend)
		return;

	mb();

	for (; p < vend - clflush_size; p += clflush_size)
		clflushopt(p);

	clflush(p);		/* Serializing and thus a barrier */
}

  reply	other threads:[~2016-01-07 22:30 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-19  9:58 [PATCH] x86: Add an explicit barrier() to clflushopt() Chris Wilson
2015-10-19 10:16 ` Borislav Petkov
2015-10-19 11:05   ` Chris Wilson
2015-10-19 11:25     ` Borislav Petkov
2015-10-19 18:29 ` Ross Zwisler
2016-01-07 10:16 ` Chris Wilson
2016-01-07 17:55   ` Andy Lutomirski
2016-01-07 19:44     ` Chris Wilson
2016-01-07 21:05       ` H. Peter Anvin
2016-01-07 21:54         ` Chris Wilson
2016-01-07 22:29           ` H. Peter Anvin [this message]
2016-01-07 22:32             ` H. Peter Anvin
2016-01-09  5:55               ` H. Peter Anvin
2016-01-09  8:01               ` Chris Wilson
2016-01-09 22:36                 ` Andy Lutomirski
2016-01-11 11:28                   ` Chris Wilson
2016-01-11 20:11                     ` Linus Torvalds
2016-01-11 21:05                       ` Chris Wilson
2016-01-12 16:37                         ` Chris Wilson
2016-01-12 17:05                           ` Linus Torvalds
2016-01-12 21:13                             ` Chris Wilson
2016-01-12 22:07                               ` Linus Torvalds
2016-01-13  0:55                                 ` Chris Wilson
2016-01-13  2:06                                   ` Linus Torvalds
2016-01-13  2:42                                     ` Andy Lutomirski
2016-01-13  4:39                                       ` Linus Torvalds
2016-01-13 12:34                                     ` Chris Wilson
2016-01-13 18:45                                       ` Linus Torvalds
2016-01-12 17:17                     ` H. Peter Anvin

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=568EE6E6.4000904@zytor.com \
    --to=hpa@zytor.com \
    --cc=bp@alien8.de \
    --cc=brgerst@gmail.com \
    --cc=chris@chris-wilson.co.uk \
    --cc=daniel.vetter@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=dvlasenk@redhat.com \
    --cc=hpa@linux.intel.com \
    --cc=imre.deak@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=ross.zwisler@linux.intel.com \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    /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;
as well as URLs for NNTP newsgroup(s).