Linux PARISC architecture development
 help / color / mirror / Atom feed
From: Grant Grundler <grundler@parisc-linux.org>
To: Kyle McMartin <kyle@mcmartin.ca>
Cc: Carlos O'Donell <carlos@systemhalted.org>,
	Grant Grundler <grundler@parisc-linux.org>,
	Helge Deller <deller@gmx.de>,
	linux-parisc <linux-parisc@vger.kernel.org>,
	John David Anglin <dave@hiauly1.hia.nrc.ca>
Subject: Re: futex.c and EWOULDBLOCK vs. EAGAIN patch
Date: Sat, 15 May 2010 16:59:52 -0600	[thread overview]
Message-ID: <20100515225952.GD7587@lackof.org> (raw)
In-Reply-To: <20100515172749.GE6764@bombadil.infradead.org>

On Sat, May 15, 2010 at 01:27:49PM -0400, Kyle McMartin wrote:
> It's a two instruction penalty(*) in the kernel syscall return path, just
> do it there. I've got a box at Red Hat with all the source to the whole
> damn world on it we run greps against to look for dumb stuff like memcpy
> bugs.

Why look for it? Just change the kernel to not ever return one of them.

>  I'll toss a grep for EAGAIN and not EWOULDBLOCK and vice versa and
> see how much stuff might b0rk.

Please do...I'd be curious to see which programs might be affected and
if we care.

> We discussed this a couple years ago, and it ended up being a complete
> rats nest of error returns that needed fixing.
> 
> regards, Kyle.
> 
> *: CMPI,N(=), LDI, maybe a third since I don't remember how sign
> extension works off the top of my head.

Mispredicted branches cost something like 20-25 cycles. I forgot now but I
do know they aren't cheap.

I'd rather not add more hacks for this they are unlikely to ever
be removed again. I'd rather have status quo than add some hack
to the syscall return path.

thanks,
grant


  reply	other threads:[~2010-05-15 22:59 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-10 19:41 futex.c and EWOULDBLOCK vs. EAGAIN patch Helge Deller
2010-05-14 19:20 ` Grant Grundler
2010-05-15 11:24   ` Carlos O'Donell
2010-05-15 17:27     ` Kyle McMartin
2010-05-15 22:59       ` Grant Grundler [this message]
2010-05-15 23:03         ` Kyle McMartin
2010-05-16 16:12           ` Grant Grundler
2010-05-16 16:25             ` Kyle McMartin
2010-05-17 19:39       ` Carlos O'Donell
2010-05-15 22:54     ` Grant Grundler
2010-05-16  0:38 ` John David Anglin

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=20100515225952.GD7587@lackof.org \
    --to=grundler@parisc-linux.org \
    --cc=carlos@systemhalted.org \
    --cc=dave@hiauly1.hia.nrc.ca \
    --cc=deller@gmx.de \
    --cc=kyle@mcmartin.ca \
    --cc=linux-parisc@vger.kernel.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