All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nathan Lynch <ntl@pobox.com>
To: Paul Jackson <pj@sgi.com>
Cc: dino@in.ibm.com, Simon.Derr@bull.net,
	lse-tech@lists.sourceforge.net, akpm@osdl.org,
	nickpiggin@yahoo.com.au, vatsa@in.ibm.com,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] cpusets+hotplug+preepmt broken
Date: Thu, 12 May 2005 19:34:08 -0500	[thread overview]
Message-ID: <20050513003408.GG3614@otto> (raw)
In-Reply-To: <20050511134235.5cecf85c.pj@sgi.com>

Paul Jackson wrote:
> 
> I share you preference for not nesting these semaphores.
> 
> The other choice I am aware of would be for the hotplug code to be less
> cpuset-friendly.  In the move_task_off_dead_cpu() code, at the point it
> says "No more Mr. Nice Guy", instead of looking for the nearest
> enclosing cpuset that has something online, which is what the
> cpuset_cpus_allowed() does, instead we could just take any damn cpu that
> was online.
> 
> Something along the lines of the following fix:
> 
> --- pj/kernel.old/sched.c	2005-05-11 13:00:17.000000000 -0700
> +++ pj/kernel.new/sched.c	2005-05-11 13:02:24.000000000 -0700
> @@ -4229,7 +4229,7 @@ static void move_task_off_dead_cpu(int d
>  
>  	/* No more Mr. Nice Guy. */
>  	if (dest_cpu == NR_CPUS) {
> -		tsk->cpus_allowed = cpuset_cpus_allowed(tsk);
> +		tsk->cpus_allowed = cpu_online_map;
>  		dest_cpu = any_online_cpu(tsk->cpus_allowed);

Well, CPU_MASK_ALL rather than cpu_online_map, I would think.  That is
what the behavior was before the cpuset merge, anyway.  It might be
the best short term solution, more below...

> So what we'd really like to do would be to first fallback to all the
> cpus allowed in the specified tasks cpuset (no walking the cpuset
> hierarchy), and see if any of those cpus are still online to receive
> this orphan task.  Unless someone has botched the system configuration,
> and taken offline all the cpus in a cpuset, this should yield up a cpu
> that is still both allowed and online.  If that fails, then to heck with
> honoring cpuset placement - just take the first online cpu we can find.
> 
> This is doable without holding cpuset_sem.  We can look at a current
> tasks cpuset without cpuset_sem, just with the task lock.

Yes, but your patch doesn't lock the task itself (unless I'm
misreading patches again).  However, have a look at the comments above
task_lock in sched.h:

/*
 * Protects ->fs, ->files, ->mm, ->ptrace, ->group_info, ->comm, keyring
 * subscriptions and synchronises with wait4().  Also used in procfs.
 *
 * Nests both inside and outside of read_lock(&tasklist_lock).
 * It must not be nested with write_lock_irq(&tasklist_lock),
 * neither inside nor outside.
 */
static inline void task_lock(struct task_struct *p)
{
        spin_lock(&p->alloc_lock);
}


Unfortunately, move_task_off_dead_cpu is called from
migrate_live_tasks while the latter has a write_lock_irq on
tasklist_lock.  So we can't use task_lock in this context, assuming
the comments are valid.  Right?


Nathan

  parent reply	other threads:[~2005-05-13  0:34 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-05-11 19:16 [PATCH] cpusets+hotplug+preepmt broken Dinakar Guniguntala
2005-05-11 19:25 ` [Lse-tech] " Paul Jackson
2005-05-11 19:55   ` Paul Jackson
2005-05-11 20:26     ` Nathan Lynch
2005-05-11 20:45       ` Paul Jackson
2005-05-11 19:51 ` Nathan Lynch
2005-05-11 20:42   ` Paul Jackson
2005-05-11 20:58     ` Paul Jackson
2005-05-14  2:23       ` Paul Jackson
2005-05-14 12:14         ` Nathan Lynch
2005-05-14 17:04           ` Paul Jackson
2005-05-14 17:44             ` Paul Jackson
2005-05-18  4:14               ` Paul Jackson
2005-05-18  9:29               ` [Lse-tech] " Dinakar Guniguntala
2005-05-18 14:48               ` Nathan Lynch
2005-05-18 21:16               ` Paul Jackson
2005-05-14 16:28         ` Srivatsa Vaddagiri
2005-05-12 15:10     ` Dinakar Guniguntala
2005-05-13 12:15       ` [Lse-tech] " Dinakar Guniguntala
2005-05-13  0:34     ` Nathan Lynch [this message]
2005-05-13 12:32   ` Dinakar Guniguntala
2005-05-13 17:25     ` Srivatsa Vaddagiri
2005-05-13 19:59       ` Paul Jackson
2005-05-13 20:20         ` Dipankar Sarma
2005-05-13 20:46           ` Nathan Lynch
2005-05-13 21:05             ` Paul Jackson
2005-05-13 21:06             ` Dipankar Sarma
2005-05-13 20:52           ` Paul Jackson
2005-05-13 21:02             ` Dipankar Sarma
2005-05-14  2:58               ` Paul Jackson
2005-05-14 16:09                 ` Srivatsa Vaddagiri
2005-05-14 17:50                   ` Paul Jackson
2005-05-14 17:57                   ` Paul Jackson
2005-05-14 16:30                 ` Nathan Lynch
2005-05-14 17:23                   ` Srivatsa Vaddagiri
2005-05-14 23:17                     ` Nathan Lynch
2005-05-13 19:59     ` Paul Jackson
2005-05-13 21:27     ` Nathan Lynch

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=20050513003408.GG3614@otto \
    --to=ntl@pobox.com \
    --cc=Simon.Derr@bull.net \
    --cc=akpm@osdl.org \
    --cc=dino@in.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lse-tech@lists.sourceforge.net \
    --cc=nickpiggin@yahoo.com.au \
    --cc=pj@sgi.com \
    --cc=vatsa@in.ibm.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.