LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Max Krasnyansky <maxk@qualcomm.com>
To: Paul Jackson <pj@sgi.com>
Cc: a.p.zijlstra@chello.nl, linux-kernel@vger.kernel.org,
mingo@elte.hu, srostedt@redhat.com, ghaskins@novell.com
Subject: Re: Integrating cpusets and cpu isolation [was Re: [CPUISOL] CPU isolation extensions]
Date: Sat, 02 Feb 2008 21:57:55 -0800 [thread overview]
Message-ID: <47A557E3.4080206@qualcomm.com> (raw)
In-Reply-To: <20080202001612.98354ff2.pj@sgi.com>
Paul Jackson wrote:
> Max wrote:
>> Here is the list of things of issues with sched_load_balance flag from CPU isolation
>> perspective:
>
> A separate thread happened to start up on lkml.org, shortly after
> yours, that went into this in considerable detail.
>
> For example, the interaction of cpusets, sched_load_balance,
> sched_domains and real time scheduling is examined in some detail on
> this thread. Everyone participating on that thread learned something
> (we all came into it with less than a full picture of what's there.)
>
> I would encourage you to read it closely. For example, the scheduler
> code should not be trying to access per-cpuset attributes such as
> the sched_load_balance flag (you are correct that this would be
> difficult to do because of the locking; however by design, that is
> not to be done.)
>
> This thread begins at:
>
> scheduler scalability - cgroups, cpusets and load-balancing
> http://lkml.org/lkml/2008/1/29/60
>
> Too bad we didn't think to include you in the CC list of that
> thread from the beginning.
Paul, I actually mentioned at the beginning of my email that I did read that thread
started by Peter. I did learn quite a bit from it :)
You guys did not discuss isolation stuff though. The thread was only about scheduling
and my cpu isolation extension patches deal with other aspects.
Sounds like at this point we're in agreement that sched_load_balance is not suitable
for what I'd like to achieve. But how about making cpusets aware of the cpu_isolated_map ?
Even without my patches it's somewhat of an issue right now. I mean of you use isolcpus=
boot option to put cpus into null domain, cpusets will not be aware of it. The result maybe
a bit confusing if an isolated cpu is added to some cpuset.
Max
next prev parent reply other threads:[~2008-02-03 5:59 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-28 4:09 [CPUISOL] CPU isolation extensions maxk
2008-01-28 4:09 ` [PATCH] [CPUISOL] Add config options for CPU isolation maxk
2008-01-28 4:09 ` [PATCH] [CPUISOL] Export CPU isolation bits maxk
2008-01-28 4:09 ` [PATCH] [CPUISOL] Do not route IRQs to the CPUs isolated at boot maxk
2008-01-28 4:09 ` [PATCH] [CPUISOL] Support for workqueue isolation maxk
2008-01-28 4:09 ` [PATCH] [CPUISOL] Isolated CPUs should be ignored by the "stop machine" maxk
2008-01-28 9:08 ` [CPUISOL] CPU isolation extensions Peter Zijlstra
2008-01-28 14:59 ` Paul Jackson
2008-01-28 16:34 ` Steven Rostedt
2008-01-28 16:44 ` Peter Zijlstra
2008-01-28 18:54 ` Max Krasnyanskiy
2008-01-28 18:46 ` Max Krasnyanskiy
2008-01-28 19:00 ` Steven Rostedt
2008-01-28 20:22 ` Peter Zijlstra
2008-01-28 21:42 ` Max Krasnyanskiy
2008-02-05 0:32 ` CPU isolation and workqueues [was Re: [CPUISOL] CPU isolation extensions] Max Krasnyanskiy
2008-01-28 18:37 ` [CPUISOL] CPU isolation extensions Max Krasnyanskiy
2008-01-28 19:06 ` Paul Jackson
2008-01-28 21:47 ` Max Krasnyanskiy
2008-01-31 19:06 ` Integrating cpusets and cpu isolation [was Re: [CPUISOL] CPU isolation extensions] Max Krasnyanskiy
2008-02-02 6:16 ` Paul Jackson
2008-02-03 5:57 ` Max Krasnyansky [this message]
2008-02-03 7:53 ` Paul Jackson
2008-02-04 6:03 ` Max Krasnyansky
2008-02-04 10:54 ` Paul Jackson
2008-02-04 23:19 ` Max Krasnyanskiy
2008-02-05 2:46 ` Paul Jackson
2008-02-05 4:08 ` Max Krasnyansky
2008-01-28 18:32 ` [CPUISOL] CPU isolation extensions Max Krasnyanskiy
2008-01-28 19:10 ` Paul Jackson
2008-01-28 23:41 ` Daniel Walker
2008-01-29 0:12 ` Max Krasnyanskiy
2008-01-29 1:33 ` Daniel Walker
2008-02-04 6:53 ` Max Krasnyansky
2008-01-31 12:16 ` Mark Hounschell
2008-01-31 19:13 ` Max Krasnyanskiy
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=47A557E3.4080206@qualcomm.com \
--to=maxk@qualcomm.com \
--cc=a.p.zijlstra@chello.nl \
--cc=ghaskins@novell.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=pj@sgi.com \
--cc=srostedt@redhat.com \
--subject='Re: Integrating cpusets and cpu isolation [was Re: [CPUISOL] CPU isolation extensions]' \
/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
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).