On Fri, Aug 19, 2005 at 05:27:24PM +0400, Oleg Nesterov wrote:
> Paul E. McKenney wrote:
> >
> > I have indeed been thinking along these lines, but all of the devil plans
> > that I have come up thus far are quite intrusive, and might have some
> > performance problems in some situations. So it se
Paul E. McKenney wrote:
>
> I have indeed been thinking along these lines, but all of the devil plans
> that I have come up thus far are quite intrusive, and might have some
> performance problems in some situations. So it seems best to remove
> tasklist_lock in steps:
>
> 1.Single-recipient c
On Thu, Aug 18, 2005 at 03:48:00PM +0400, Oleg Nesterov wrote:
> Paul E. McKenney wrote:
> >
> > On Wed, Aug 17, 2005 at 06:35:03PM +0400, Oleg Nesterov wrote:
> > >
> > > Sorry, I don't understand you. CLONE_THREAD implies CLONE_SIGHAND,
> > > so we always need to lock one ->sighand. Could you ple
(Replying to wrong message, sorry).
Thomas Gleixner wrote:
>
> --- linux-2.6.13-rc6-rt8/kernel/fork.c2005-08-17 12:57:08.0
> +0200
> +++ linux-2.6.13-rc6-rt/kernel/fork.c 2005-08-17 11:17:46.0 +0200
> @@ -1198,7 +1198,8 @@ bad_fork_cleanup_mm:
> bad_fork_cleanup_signal:
>
Paul E. McKenney wrote:
>
> On Wed, Aug 17, 2005 at 06:35:03PM +0400, Oleg Nesterov wrote:
> >
> > Sorry, I don't understand you. CLONE_THREAD implies CLONE_SIGHAND,
> > so we always need to lock one ->sighand. Could you please clarify?
>
> On the #3 and #4 code paths, the code assumes that the tas
On Wed, Aug 17, 2005 at 06:35:03PM +0400, Oleg Nesterov wrote:
> Paul E. McKenney wrote:
> >
> > > The other thing that jumped out at me is that signals are very different
> > > animals from a locking viewpoint depending on whether they are:
> > >
> > > 1.ignored,
> > >
> > > 2.caug
Paul E. McKenney wrote:
>
> > The other thing that jumped out at me is that signals are very different
> > animals from a locking viewpoint depending on whether they are:
> >
> > 1. ignored,
> >
> > 2. caught by a single thread,
> >
> > 3. fatal to multiple threads/processes (though I don't know
* Paul E. McKenney <[EMAIL PROTECTED]> wrote:
> My tests are not finding even glaring races, so time to go and create
> some torture tests before getting too much more elaborate. 10,000
> eyes are nice (and Oleg's eyes do seem to be working especially well),
> but a good software-test sledgeh
On Tue, Aug 16, 2005 at 10:07:14AM -0700, Paul E. McKenney wrote:
> On Tue, Aug 16, 2005 at 03:56:05PM +0400, Oleg Nesterov wrote:
> > Paul E. McKenney wrote:
> > >
> > > OK, the attached instead revalidates that the task struct still references
> > > the sighand_struct after obtaining the lock
> >
On Tue, Aug 16, 2005 at 03:56:05PM +0400, Oleg Nesterov wrote:
> Paul E. McKenney wrote:
> >
> > OK, the attached instead revalidates that the task struct still references
> > the sighand_struct after obtaining the lock
>
> Personally I think this is a way to go. A nitpick suggestion,
> could you
Paul E. McKenney wrote:
>
> OK, the attached instead revalidates that the task struct still references
> the sighand_struct after obtaining the lock
Personally I think this is a way to go. A nitpick suggestion,
could you make a separate function (say, lock_task_sighand)
which does all this job?
>
* Paul E. McKenney <[EMAIL PROTECTED]> wrote:
> OK, the attached instead revalidates that the task struct still
> references the sighand_struct after obtaining the lock (and passes
> kernbench and LTP, which tells me I need to get better tests!).
i've applied this to the -RT tree, and it's loo
On Fri, Aug 12, 2005 at 12:51:17PM +0400, Oleg Nesterov wrote:
> Paul E. McKenney wrote:
> >
> > --- linux-2.6.13-rc4-realtime-preempt-V0.7.53-01/fs/exec.c 2005-08-11
> > 11:44:55.0 -0700
> > +++ linux-2.6.13-rc4-realtime-preempt-V0.7.53-01-tasklistRCU/fs/exec.c
> > 2005-08-11 12:26
On Fri, Aug 12, 2005 at 08:36:00AM +0200, Ingo Molnar wrote:
>
> * Lee Revell <[EMAIL PROTECTED]> wrote:
>
> > Doesn't this fix the longest latency we were seeing with
> > PREEMPT_DESKTOP, I don't have a trace handy but the upshot was "signal
> > delivery must remain atomic on !PREEMPT_RT"?
>
On Fri, Aug 12, 2005 at 12:51:17PM +0400, Oleg Nesterov wrote:
> Paul E. McKenney wrote:
> >
> > --- linux-2.6.13-rc4-realtime-preempt-V0.7.53-01/fs/exec.c 2005-08-11
> > 11:44:55.0 -0700
> > +++ linux-2.6.13-rc4-realtime-preempt-V0.7.53-01-tasklistRCU/fs/exec.c
> > 2005-08-11 12:26
Paul E. McKenney wrote:
>
> --- linux-2.6.13-rc4-realtime-preempt-V0.7.53-01/fs/exec.c2005-08-11
> 11:44:55.0 -0700
> +++ linux-2.6.13-rc4-realtime-preempt-V0.7.53-01-tasklistRCU/fs/exec.c
> 2005-08-11 12:26:45.0 -0700
> [ ... snip ... ]
> @@ -785,11 +787,13 @@ no_threa
* Lee Revell <[EMAIL PROTECTED]> wrote:
> Doesn't this fix the longest latency we were seeing with
> PREEMPT_DESKTOP, I don't have a trace handy but the upshot was "signal
> delivery must remain atomic on !PREEMPT_RT"?
yes - although Paul's patch converts only a portion of the signal code
to
On Thu, 2005-08-11 at 11:56 +0200, Ingo Molnar wrote:
> > For the record, some shortcomings of this patch:
> >
> > o Needs lots more testing on more architectures.
> >
> > o Needs performance and stress testing.
> >
> > o Needs testing in Ingo's PREEMPT_RT environment.
>
> cool patch! I h
On Thu, Aug 11, 2005 at 04:16:53PM +0400, Oleg Nesterov wrote:
> Paul E. McKenney wrote:
> >
> > --- linux-2.6.13-rc6/kernel/signal.c2005-08-08 19:59:24.0
> > -0700
> > +++ linux-2.6.13-rc6-tasklistRCU/kernel/signal.c2005-08-10
> > 08:20:25.0 -0700
> > @@ -1151,9 +1151
On Thu, Aug 11, 2005 at 11:30:44PM +0530, Dipankar Sarma wrote:
> When I worked on this last (a year or so ago), it seemed that I would
> need to put a number of additional structures under RCU control.
> It would be better to gradually move it towards RCU rather than
> trying make all the readers
On Thu, Aug 11, 2005 at 06:14:51PM +0100, Christoph Hellwig wrote:
> On Wed, Aug 10, 2005 at 10:11:45AM -0700, Paul E. McKenney wrote:
> > Hello!
> >
> > This patch is an experiment in use of RCU for individual code paths that
> > read-acquire the tasklist lock, in this case, unicast signal delive
On Thu, Aug 11, 2005 at 06:14:51PM +0100, Christoph Hellwig wrote:
> On Wed, Aug 10, 2005 at 10:11:45AM -0700, Paul E. McKenney wrote:
> > Hello!
> >
> > This patch is an experiment in use of RCU for individual code paths that
> > read-acquire the tasklist lock, in this case, unicast signal delive
On Wed, Aug 10, 2005 at 10:11:45AM -0700, Paul E. McKenney wrote:
> Hello!
>
> This patch is an experiment in use of RCU for individual code paths that
> read-acquire the tasklist lock, in this case, unicast signal delivery.
> It passes five kernbenches on 4-CPU x86, but obviously needs much more
On Thu, Aug 11, 2005 at 04:16:53PM +0400, Oleg Nesterov wrote:
> Paul E. McKenney wrote:
> >
> > --- linux-2.6.13-rc6/kernel/signal.c2005-08-08 19:59:24.0
> > -0700
> > +++ linux-2.6.13-rc6-tasklistRCU/kernel/signal.c2005-08-10
> > 08:20:25.0 -0700
> > @@ -1151,9 +1151
On Thu, Aug 11, 2005 at 11:56:34AM +0200, Ingo Molnar wrote:
>
> * Paul E. McKenney <[EMAIL PROTECTED]> wrote:
>
> > Hello!
> >
> > This patch is an experiment in use of RCU for individual code paths
> > that read-acquire the tasklist lock, in this case, unicast signal
> > delivery. It passes
Paul E. McKenney wrote:
>
> --- linux-2.6.13-rc6/kernel/signal.c 2005-08-08 19:59:24.0 -0700
> +++ linux-2.6.13-rc6-tasklistRCU/kernel/signal.c 2005-08-10
> 08:20:25.0 -0700
> @@ -1151,9 +1151,13 @@ int group_send_sig_info(int sig, struct
>
> ret = check_kill_permissio
* Paul E. McKenney <[EMAIL PROTECTED]> wrote:
> Hello!
>
> This patch is an experiment in use of RCU for individual code paths
> that read-acquire the tasklist lock, in this case, unicast signal
> delivery. It passes five kernbenches on 4-CPU x86, but obviously needs
> much more testing befor
Hello!
This patch is an experiment in use of RCU for individual code paths that
read-acquire the tasklist lock, in this case, unicast signal delivery.
It passes five kernbenches on 4-CPU x86, but obviously needs much more
testing before it is considered for serious use, let alone inclusion.
My ma
28 matches
Mail list logo
