public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: george anzinger <george@mvista.com>
To: Rusty Russell <rusty@rustcorp.com.au>
Cc: nigel@nrg.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH for 2.5] preemptible kernel
Date: Sat, 31 Mar 2001 23:48:04 -0800	[thread overview]
Message-ID: <3AC6DD34.5B030E96@mvista.com> (raw)
In-Reply-To: <m14j5FD-001PKFC@mozart>

Rusty Russell wrote:
> 
> In message <Pine.LNX.4.05.10103291555390.8122-100000@cosmic.nrg.org> you write:
> > Here is an attempt at a possible version of synchronize_kernel() that
> > should work on a preemptible kernel.  I haven't tested it yet.
> 
> It's close, but...
> 
> Those who suggest that we don't do preemtion on SMP make this much
> easier (synchronize_kernel() is a NOP on UP), and I'm starting to
> agree with them.  Anyway:
> 
> >               if (p->state == TASK_RUNNING ||
> >                               (p->state == (TASK_RUNNING|TASK_PREEMPTED))) {
> >                       p->flags |= PF_SYNCING;
> 
> Setting a running task's flags brings races, AFAICT, and checking
> p->state is NOT sufficient, consider wait_event(): you need p->has_cpu
> here I think.  You could do it for TASK_PREEMPTED only, but you'd have
> to do the "unreal priority" part of synchronize_kernel() with some
> method to say "don't preempt anyone", but it will hurt latency.
> Hmmm...
> 
> The only way I can see is to have a new element in "struct
> task_struct" saying "syncing now", which is protected by the runqueue
> lock.  This looks like (and I prefer wait queues, they have such nice
> helpers):
> 
>         static DECLARE_WAIT_QUEUE_HEAD(syncing_task);
>         static DECLARE_MUTEX(synchronize_kernel_mtx);
>         static int sync_count = 0;
> 
> schedule():
>         if (!(prev->state & TASK_PREEMPTED) && prev->syncing)
>                 if (--sync_count == 0) wake_up(&syncing_task);
> 
> synchronize_kernel():
> {
>         struct list_head *tmp;
>         struct task_struct *p;
> 
>         /* Guard against multiple calls to this function */
>         down(&synchronize_kernel_mtx);
> 
>         /* Everyone running now or currently preempted must
>            voluntarily schedule before we know we are safe. */
>         spin_lock_irq(&runqueue_lock);
>         list_for_each(tmp, &runqueue_head) {
>                 p = list_entry(tmp, struct task_struct, run_list);
>                 if (p->has_cpu || p->state == (TASK_RUNNING|TASK_PREEMPTED)) {
I think this should be:
	          if (p->has_cpu || p->state & TASK_PREEMPTED)) {
to catch tasks that were preempted with other states.  The lse Multi
Queue scheduler folks are going to love this.

George

>                         p->syncing = 1;
>                         sync_count++;
>                 }
>         }
>         spin_unlock_irq(&runqueue_lock);
> 
>         /* Wait for them all */
>         wait_event(syncing_task, sync_count == 0);
>         up(&synchronize_kernel_mtx);
> }
> 
> Also untested 8),
> Rusty.
> --
> Premature optmztion is rt of all evl. --DK
> -
> 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	other threads:[~2001-04-01  7:53 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
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 [this message]
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=3AC6DD34.5B030E96@mvista.com \
    --to=george@mvista.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nigel@nrg.org \
    --cc=rusty@rustcorp.com.au \
    /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