All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oleg Nesterov <oleg@redhat.com>
To: Rakib Mullick <rakib.mullick@gmail.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
	Ingo Molnar <mingo@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: Do we really need curr_target in signal_struct ?
Date: Wed, 29 Jan 2014 15:55:35 +0100	[thread overview]
Message-ID: <20140129145535.GA12562@redhat.com> (raw)
In-Reply-To: <CADZ9YHhx3NkeQp4S=o0ruAd7U20AprFt-uejcqn1oLzJbm3w4A@mail.gmail.com>

On 01/29, Rakib Mullick wrote:
>
> On Tue, Jan 28, 2014 at 10:43 PM, Oleg Nesterov <oleg@redhat.com> wrote:
>
> > But I guess ->curr_target was added exactly to avoid this loop if
> > possible, assuming that wants_signal(->current_targer) should be
> > likely true. Although perhaps this optimization is too simple.
> >
> Well, this code block will only hit when first check for wants_signal()
> will miss,

Yes,

> that means we need to find some other thread of the group.

Yes,

> AFAIU, ->current_target is only a loop breaker to avoid infinite loop,

No. It caches the last result of "find a thread which can handle this
group-wide signal".

> but - by using while_each_thread() we can remove it completely, thus
> helps to get rid from maintaining it too.

... and remove the optimization above.

> I'll prepare a proper patch with you suggestions for reviewing.

I am not sure we want this patch. Once again, I do not know how much
->curr_target helps, and certainaly it can't help always. But you
should not blindly remove it just because yes, sure, it is not strictly
needed to find a wants_signal() thread.

Oleg.


  parent reply	other threads:[~2014-01-29 14:55 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-28  7:57 Do we really need curr_target in signal_struct ? Rakib Mullick
2014-01-28 16:43 ` Oleg Nesterov
2014-01-29  4:09   ` Rakib Mullick
2014-01-29  4:45     ` Rakib Mullick
2014-01-29 14:55     ` Oleg Nesterov [this message]
2014-01-29 16:07       ` Rakib Mullick
2014-01-29 18:32         ` Oleg Nesterov
2014-01-30  7:02           ` Rakib Mullick
2014-01-31 18:53             ` Rakib Mullick
2014-02-01 16:51               ` Oleg Nesterov
2014-02-02 16:50                 ` Rakib Mullick
2014-02-03 16:39                   ` Oleg Nesterov
2014-02-04  4:32                     ` Rakib Mullick
2014-02-04 17:34                       ` Oleg Nesterov

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=20140129145535.GA12562@redhat.com \
    --to=oleg@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=rakib.mullick@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.