public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: george anzinger <george@mvista.com>
To: Dipankar Sarma <dipankar@sequent.com>
Cc: nigel@nrg.org, linux-kernel@vger.kernel.org, mckenney@sequent.com
Subject: Re: [PATCH for 2.5] preemptible kernel
Date: Wed, 28 Mar 2001 12:51:02 -0800	[thread overview]
Message-ID: <3AC24EB6.1F0DD551@mvista.com> (raw)
In-Reply-To: 3AC1BAD3.BBBD97E1@sequent.com

Dipankar Sarma wrote:
> 
> Nigel Gamble wrote:
> >
> > On Wed, 21 Mar 2001, Keith Owens wrote:
> > > I misread the code, but the idea is still correct.  Add a preemption
> > > depth counter to each cpu, when you schedule and the depth is zero then
> > > you know that the cpu is no longer holding any references to quiesced
> > > structures.
> >
> > A task that has been preempted is on the run queue and can be
> > rescheduled on a different CPU, so I can't see how a per-CPU counter
> > would work.  It seems to me that you would need a per run queue
> > counter, like the example I gave in a previous posting.
> 
> Also, a task could be preempted and then rescheduled on the same cpu
> making
> the depth counter 0 (right ?), but it could still be holding references
> to data
> structures to be updated using synchronize_kernel(). There seems to be
> two
> approaches to tackle preemption -
> 
> 1. Disable pre-emption during the time when references to data
> structures
> updated using such Two-phase updates are held.

Doesn't this fly in the face of the whole Two-phase system?  It seems to
me that the point was to not require any locks.  Preemption disable IS a
lock.  Not as strong as some, but a lock none the less.
> 
> Pros: easy to implement using a flag (ctx_sw_off() ?)
> Cons: not so easy to use since critical sections need to be clearly
> identified and interfaces defined. also affects preemptive behavior.
> 
> 2. In synchronize_kernel(), distinguish between "natural" and preemptive
> schedules() and ignore preemptive ones.
> 
> Pros: easy to use
> Cons: Not so easy to implement. Also a low priority task that keeps
> getting
> preempted often can affect update side performance significantly.

Actually is is fairly easy to distinguish the two (see TASK_PREEMPTED in
state).  Don't you also have to have some sort of task flag that
indicates that the task is one that needs to sync?  Something that gets
set when it enters the area of interest and cleared when it hits the
sync point?  

George

  reply	other threads:[~2001-03-28 20:57 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-03-15  1:25 [PATCH for 2.5] preemptible kernel Nigel Gamble
2001-03-17 17:34 ` Pavel Machek
2001-03-19 21:01   ` Nigel Gamble
2001-03-20  8:43 ` Rusty Russell
2001-03-20  9:32   ` Keith Owens
2001-03-21  0:48     ` Nigel Gamble
2001-03-21  1:23       ` Keith Owens
2001-03-21  3:35         ` Nigel Gamble
2001-03-21  8:04           ` george anzinger
2001-03-21  9:04             ` Keith Owens
2001-03-21 14:32             ` Rusty Russell
2001-03-23 20:42               ` Nigel Gamble
2001-03-28 11:47             ` Dipankar Sarma
2001-03-21  9:19           ` Keith Owens
2001-03-21  9:41             ` David S. Miller
2001-03-21 10:05               ` Andrew Morton
2001-03-22  0:20                 ` Nigel Gamble
2001-03-21 10:57               ` george anzinger
2001-03-21 11:30                 ` David S. Miller
2001-03-21 17:07                   ` george anzinger
2001-03-21 18:18               ` Nigel Gamble
2001-03-21 22:25               ` Rusty Russell
2001-03-21 15:46             ` Andrea Arcangeli
2001-03-28 10:20           ` Dipankar Sarma
2001-03-28 20:51             ` george anzinger [this message]
2001-03-29  9:43               ` Dipankar Sarma
2001-03-30  6:32               ` Keith Owens
2001-03-21  0:24   ` Nigel Gamble
2001-03-30  0:26     ` Nigel Gamble
2001-03-30 20:11       ` Rusty Russell
2001-04-01  7:48         ` george anzinger
2001-04-01 21:13           ` Nigel Gamble
2001-04-02 19:56             ` george anzinger
2001-04-04 17:59               ` Rusty Russell
2001-04-01 21:07         ` Nigel Gamble
2001-04-04 17:51           ` Rusty Russell
2001-03-20 18:25 ` Roger Larsson
2001-03-20 22:06   ` Nigel Gamble
2001-03-20 22:27     ` george anzinger
  -- strict thread matches above, loose matches on Subject: below --
2001-04-06 23:52 Paul McKenney
2001-04-07  0:45 ` Andi Kleen
2001-04-07  1:25 Paul McKenney
2001-04-07 19:59 ` Rusty Russell

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=3AC24EB6.1F0DD551@mvista.com \
    --to=george@mvista.com \
    --cc=dipankar@sequent.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mckenney@sequent.com \
    --cc=nigel@nrg.org \
    /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