mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Paul Mackerras <paulus@samba.org>
To: David Howells <dhowells@redhat.com>
Cc: torvalds@transmeta.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] syscall latency improvement #1
Date: Sat, 26 Jan 2002 10:07:54 +1100 (EST)	[thread overview]
Message-ID: <15441.58698.88184.111366@argo.ozlabs.ibm.com> (raw)
In-Reply-To: <18993.1011984842@warthog.cambridge.redhat.com>
In-Reply-To: <18993.1011984842@warthog.cambridge.redhat.com>

David Howells writes:

> The attached patch does the following to 2.5.3-pre5:
> 
>  * consolidates various status items that are found in the lower reaches of
>    task_struct into one 32-bit word, thus allowing them to be tested
>    atomically without the need to disable interrupts in entry.S.

I'm no expert on the x86 arch-specific code, but it looks to me like
you have misunderstood what is going on there.  It seems to me that
you have opened up a race by testing the need_resched and sigpending
flags with interrupts enabled.  The race is that you can test those
flags and find them false, and then get an interrupt that sets one or
other of those flags.  You will then return to the usermode process
and not act on the need_resched or sigpending until the next
interrupt.  So in fact you will reschedule / deliver the signal
eventually, but with extra latency.

In other words, the "atomic" in the comment is not about testing
need_resched and sigpending at the same time, but about making the
process of testing those flags and returning to usermode atomic.

Paul.

  parent reply	other threads:[~2002-01-25 23:11 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-01-25 18:54 David Howells
2002-01-25 22:35 ` Robert Love
2002-01-26 10:07   ` Nigel Gamble
2002-01-25 23:07 ` Paul Mackerras [this message]
2002-01-26  0:39 ` Linus Torvalds
2002-01-26  0:57   ` Andrew Morton
2002-01-26  1:20     ` Linus Torvalds
2002-01-26  4:00     ` Jamie Lokier
2002-01-28 14:18     ` Denis Vlasenko
2002-01-28 10:30       ` Andrew Morton
2002-01-28 15:28         ` Jeff Dike
2002-01-29 12:54         ` Pavel Machek
2002-01-29 12:59         ` Denis Vlasenko
2002-02-21  7:10           ` Cameron Simpson
2002-01-29  0:53       ` [PATCH] " Rusty Russell
2002-01-26 18:39   ` Alan Cox
2002-01-27 19:59     ` Jamie Lokier
     [not found] <18993.1011984842@warthog.cambridge.redhat.com.suse.lists.linux.kernel>
     [not found] ` <Pine.LNX.4.33.0201251626490.2042-100000@penguin.transmeta.com.suse.lists.linux.kernel>
2002-01-26  1:24   ` Andi Kleen
2002-01-26  1:53     ` Linus Torvalds
2002-01-26  2:03       ` Andi Kleen
2002-01-26  2:14         ` Linus Torvalds
2002-01-26  2:26           ` Andi Kleen
2002-01-26  2:39             ` Dave Jones
2002-01-26  2:53           ` Davide Libenzi
2002-01-26  2:10       ` Andrew Morton
2002-01-26  3:20         ` Robert Love
2002-01-26  3:06       ` Robert Love

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=15441.58698.88184.111366@argo.ozlabs.ibm.com \
    --to=paulus@samba.org \
    --cc=dhowells@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@transmeta.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

all inboxes | Powered by JetHome®