[PATCH] x86_64: fix delayed signals - Kernel

This is a discussion on [PATCH] x86_64: fix delayed signals - Kernel ; 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 ...

+ Reply to Thread
Page 3 of 3 FirstFirst 1 2 3
Results 41 to 45 of 45

Thread: [PATCH] x86_64: fix delayed signals

  1. 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@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  2. Re: [PATCH] x86_64: fix delayed signals



    On Sun, 13 Jul 2008, Oleg Nesterov wrote:
    >
    > SETFL_MASK doesn't have O_RDWR, and in any case setfl() changes ->f_flags,
    > not ->f_mode.


    I think you can still read a write-only file descriptor on some systems:
    doing a mmap( PROT_WRITE ) on it can sometimes do it.

    The reason - PROT_WRITE often implies PROT_READ (because on many CPU's you
    have to do unaligned writes with a read-modify-write cycle - on some like
    old alphas you have to do even normal byte and word writes that way).

    So if the OS checks just the asked-for protections against the file
    descriptor protections, you'll essentially get read access for free when
    you do the mmap.

    At least current versions of Linux won't ever allow a file mapping of a
    non-readable fd, but I won't guarantee we always did that, nor that other
    OS's always do it.

    Anyway, I misunderstood Edwins idea to actually throw away the writes if
    the file isn't linked anywhere and is only open for writing. I guess we
    could optimize that, but it's such an unrealistic specialc case that it
    really isn't worth it except for some benchmark-gaming kind of thing
    (which I don't like doing anyway).

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

  3. Re: [PATCH] x86_64: fix delayed signals

    In article you wrote:
    > Anyway, I misunderstood Edwins idea to actually throw away the writes if
    > the file isn't linked anywhere and is only open for writing. I guess we


    I don't understand it. The process can still clone itself and its
    children may want to look at what it has written (maybe there's too much
    file to fit in an mmap all at once) via the same file descriptor. Come
    to that, the process itself may want to look at what it's written!

    Saving memory is the idea behind writing to disk sometimes. Unlinking
    your target is sensible if you want to keep your thoughts private ..

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

  4. Re: [PATCH] x86_64: fix delayed signals

    Linus Torvalds wrote:
    >
    > 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.


    That's not how I remember it from seeing it here, but ok it's possible my
    memory is fuzzy and I'm misremembering. I'll continue to watch it.

    While the bit about color ls (which I use here) catching signals was
    also interesting I wouldn't expect the color ls to take longer to
    process Ctrl-C even if it hits user space because it shouldn't
    do anything block here (unless the terminal is in flow control,
    but is unlikely)

    > 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.


    Yes I know that, that is why the behavior always puzzled me, because
    it apparently contradicts that. I think I know reasonably well how
    signals work, but cannot say the same about tty, so my guess was
    in that area. But we'll see.

    -Andi

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

  5. Re: [PATCH] x86_64: fix delayed signals



    On Sun, 13 Jul 2008, Andi Kleen wrote:
    >
    > While the bit about color ls (which I use here) catching signals was
    > also interesting I wouldn't expect the color ls to take longer to
    > process Ctrl-C even if it hits user space because it shouldn't
    > do anything block here (unless the terminal is in flow control,
    > but is unlikely)


    I didn't take a look at the source, but I literally think that the 'ls'
    SIGINT handler is something like

    static void sigint(int signr)
    {
    exit_with_sigint = 1;
    }

    and then in the output routine it does a

    if (exit_with_sigint) {
    signal(SIGINT, SIG_DFL);
    kill(-1, SIGINT);
    }

    at the end because that's the only thing that explains that it always
    exits after printing the _first_ line of output (ignoring the header - it
    obviously doesn't have that "if (exit_with_sigint)" test in that
    code-path).

    Sad. Horrible crap. It means that it totally disables the kernels ability
    to make fatal signals break out of disk wait etc. It's also totally
    _unnecessary_, because 'ls' shouldn't even bother to block signals until
    just before it starts doing the printout.

    Oh well. You can't expect too much of user level programmers.

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

+ Reply to Thread
Page 3 of 3 FirstFirst 1 2 3