public inbox for linux-kernel@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox