Message-ID: <alpine.LFD.1.10.0807131017180.2959@woody.linux-foundation.org>
Date:	Sun, 13 Jul 2008 10:32:09 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Andi Kleen <andi@...stfloor.org>
cc:	Ingo Molnar <mingo@...e.hu>, Roland McGrath <roland@...hat.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, Elias Oltmanns <eo@...ensachen.de>,
	Török Edwin <edwintorok@...il.com>,
	Arjan van de Ven <arjan@...radead.org>
Subject: Re: [PATCH] x86_64: fix delayed signals



On Sun, 13 Jul 2008, Andi Kleen wrote:
> 
> At least the original report was about Ctrl-C only versus Ctrl-Z.

Yes, and I explained why.

> I see the problem regularly myself that Ctrl-C doesn't work,
> but Ctrl-Z+kill does (although I unfortunately cannot
> reproduce it on demand).

There's no way you _can_ reproduce it.

> But it was with programs who shouldn't catch Ctrl-C, like find.

No, it was not. I think you misread it.

Two facts:

 - ^Z and ^C are both going to be equally fast if they aren't blocked.

   This is just how things are. They are handled by the same codepaths.

 - the report you point to does mention 'find', but *not* in the place 
   where it talks about "^Z+kill". There it's much less specific, and I 
   bet that Edwin _had_ seen the "^Z works" behavior, and knew it to be 
   true, but hadn't realized that it depended on the command, so when he 
   gave an example of something where disk IO makes signals slow, he 
   happened to pick one where ^Z and ^C were equally slow.

In other words, I can pretty much _guarantee_ that if ^Z+kill is faster 
than ^C, then it's because the process blocked or caught ^C.

And I can pretty much also guarantee that when Edwin talked about 'find' 
and did that ^C cut-and-paste, he didn't try the ^Z thing (that had 
happened with _other_ programs), or if he did, it was just happenstance 
(because the latency isn't _always_ 10-30 seconds - that's just the worst 
case).

So yes, ^C often works slower. If the process catches it and removes 
temporary files as a result (for example - it's what things like gcc do), 
then of _course_ it's going to be slower. It's going to be very noticeably 
slower, especially since removing a temp-file is going to be even more 
likely to hit a filesystem lock if the write-queues are full than just a 
normal read is.

But ^C isn't always slower, and if 'find' doesn't block/ignore it (and I 
certainly believe you when you say that it doesn't), then for the case of 
'find', it won't be true that ^Z+kill is any faster.

In fact, Edwin later in this thread reported:

  "Also I wasn't able to reproduce the  'Ctrl+Z works faster than Ctrl+C'
   symptom, perhaps it is just a coincidence: by the time I press Ctrl+Z to
   interrupt, enough time has passed (30+ secs), that the same effect would
   have been obtained by another Ctrl+C, or by just waiting."

and I bet that is exactly because now he's been testing programs that 
don't block ^C (ie maybe he's now testing _just_ that "find /" thing).

So before, Edwin was probably doing random things when doing "normal 
work", and noticed that ^Z was sometimes faster. Now, he's trying to chase 
things down, and he creates this specific test-case, and for that 
particular test-case, ^Z _isn't_ faster. He just didn't pick up on the 
pattern that it depends on which particular command he works on.

Try "yum list", and you'll certainly see that ^Z works a *lot* faster than 
^C (and the latter often needs multiple ^C's even when there is no load 
at all)

			Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists