CC'ing linux-rt-users because I think my explanation below may be interesting for the
RT folks.
Mark Hounschell wrote:
Max Krasnyanskiy wrote:
With CPU isolation
it's very easy to achieve single digit usec worst case and around 200
nsec average response times on off-the-shelf
multi- processor
Max Krasnyanskiy wrote:
> With CPU isolation
> it's very easy to achieve single digit usec worst case and around 200
> nsec average response times on off-the-shelf
> multi- processor/core systems (vanilla kernel plus these patches) even
> under exteme system load.
Hi Max, could you elaborate on
It seems that git-send-email for some reasons did not send an introductory
email.
So I'm sending it manually. Sorry if you get it twice.
---
Following patch series extends CPU isolation support. Yes, most people want to virtuallize
CPUs these days and I want to isolate them :) .
The primary
Paul Jackson wrote:
> Max K wrote:
>>> And for another thing, we already declare externs in cpumask.h for
>>> the other, more widely used, cpu_*_map variables cpu_possible_map,
>>> cpu_online_map, and cpu_present_map.
>> Well, to address #2 and #3 isolated map will need to be exported
Max K wrote:
> > And for another thing, we already declare externs in cpumask.h for
> > the other, more widely used, cpu_*_map variables cpu_possible_map,
> > cpu_online_map, and cpu_present_map.
> Well, to address #2 and #3 isolated map will need to be exported as well.
> Those other m
Peter Zijlstra wrote:
On Mon, 2008-01-28 at 14:00 -0500, Steven Rostedt wrote:
On Mon, 28 Jan 2008, Max Krasnyanskiy wrote:
[PATCH] [CPUISOL] Support for workqueue isolation
The thing about workqueues is that they should only be woken on a CPU if
something on that CPU accessed them. IOW, th
Paul Jackson wrote:
Max wrote:
Looks like I failed to explain what I'm trying to achieve. So let me try again.
Well done. I read through that, expecting to disagree or at least
to not understand at some point, and got all the way through nodding
my head in agreement. Good.
Whether the earli
Max wrote:
> Looks like I failed to explain what I'm trying to achieve. So let me try
> again.
Well done. I read through that, expecting to disagree or at least
to not understand at some point, and got all the way through nodding
my head in agreement. Good.
Whether the earlier confusions were
Hi Daniel,
Sorry for not replying right away.
Daniel Walker wrote:
> On Mon, 2008-01-28 at 16:12 -0800, Max Krasnyanskiy wrote:
>
>> Not accurate enough and way too much overhead for what I need. I know at
>> this point it probably
>> sounds like I'm talking BS :). I wish I've released the eng
Paul Jackson wrote:
> Max wrote:
>> 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 :)
>
> Ah - sorry - I missed that part. However, I'm still getting the feeling
> that there were some key points in that
Max wrote:
> 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 :)
Ah - sorry - I missed that part. However, I'm still getting the feeling
that there were some key points in that thread that we have not manage
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
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,
sc
Hi Mark,
[EMAIL PROTECTED] wrote:
Following patch series extends CPU isolation support. Yes, most people want to virtuallize
CPUs these days and I want to isolate them :).
The primary idea here is to be able to use some CPU cores as dedicated engines
for running
user-space code with minimal ke
Paul Jackson wrote:
Max wrote:
So far it seems that extending cpu_isolated_map
is more natural way of propagating this notion to the rest of the kernel.
Since it's very similar to the cpu_online_map concept and it's easy to
integrated
with the code that already uses it.
If it were just realt
[EMAIL PROTECTED] wrote:
> Following patch series extends CPU isolation support. Yes, most people want
> to virtuallize
> CPUs these days and I want to isolate them :).
> The primary idea here is to be able to use some CPU cores as dedicated
> engines for running
> user-space code with minimal k
On Mon, 2008-01-28 at 16:12 -0800, Max Krasnyanskiy wrote:
> Not accurate enough and way too much overhead for what I need. I know at this
> point it probably
> sounds like I'm talking BS :). I wish I've released the engine and examples
> by now. Anyway let
> me just say that SW MAC has crazy
Daniel Walker wrote:
On Mon, 2008-01-28 at 10:32 -0800, Max Krasnyanskiy wrote:
Just this patches. RT patches cannot achieve what I needed. Even RTAI/Xenomai
can't do that.
For example I have separate tasks with hard deadlines that must be enforced in 50usec kind
of range and basically no idle
On Mon, 2008-01-28 at 10:32 -0800, Max Krasnyanskiy wrote:
> Just this patches. RT patches cannot achieve what I needed. Even RTAI/Xenomai
> can't do that.
> For example I have separate tasks with hard deadlines that must be enforced
> in 50usec kind
> of range and basically no idle time whatso
Paul Jackson wrote:
Max wrote:
So far it seems that extending cpu_isolated_map
is more natural way of propagating this notion to the rest of the kernel.
Since it's very similar to the cpu_online_map concept and it's easy to
integrated
with the code that already uses it.
If it were just realt
Peter Zijlstra wrote:
On Mon, 2008-01-28 at 14:00 -0500, Steven Rostedt wrote:
On Mon, 28 Jan 2008, Max Krasnyanskiy wrote:
[PATCH] [CPUISOL] Support for workqueue isolation
The thing about workqueues is that they should only be woken on a CPU if
something on that CPU accessed them. IOW, the
On Mon, 2008-01-28 at 14:00 -0500, Steven Rostedt wrote:
>
> On Mon, 28 Jan 2008, Max Krasnyanskiy wrote:
> > >> [PATCH] [CPUISOL] Support for workqueue isolation
> > >
> > > The thing about workqueues is that they should only be woken on a CPU if
> > > something on that CPU accessed them. IOW,
Max wrote:
> Also "CPU sets" seem to mostly deal with the scheduler domains.
True - though "cpusets" (no space ;) sched_load_balance flag can
be used to see that some CPUs are not in any scheduler domain,
which is equivalent to not having the scheduler run on them.
--
I won't r
Max wrote:
> So far it seems that extending cpu_isolated_map
> is more natural way of propagating this notion to the rest of the kernel.
> Since it's very similar to the cpu_online_map concept and it's easy to
> integrated
> with the code that already uses it.
If it were just realtime support, t
On Mon, 28 Jan 2008, Max Krasnyanskiy wrote:
> >> [PATCH] [CPUISOL] Support for workqueue isolation
> >
> > The thing about workqueues is that they should only be woken on a CPU if
> > something on that CPU accessed them. IOW, the workqueue on a CPU handles
> > work that was called by something
Peter Zijlstra wrote:
On Mon, 2008-01-28 at 11:34 -0500, Steven Rostedt wrote:
On Mon, Jan 28, 2008 at 08:59:10AM -0600, Paul Jackson wrote:
Thanks for the CC, Peter.
Thanks from me too.
Max wrote:
We've had scheduler support for CPU isolation ever since O(1) scheduler went it.
I'd like to
Steven Rostedt wrote:
On Mon, Jan 28, 2008 at 08:59:10AM -0600, Paul Jackson wrote:
Thanks for the CC, Peter.
Thanks from me too.
Max wrote:
We've had scheduler support for CPU isolation ever since O(1) scheduler went it.
I'd like to extend it further to avoid kernel activity on those CPUs
Paul Jackson wrote:
Thanks for the CC, Peter.
Ingo - see question at end of message.
Max wrote:
We've had scheduler support for CPU isolation ever since O(1) scheduler went it.
I'd like to extend it further to avoid kernel activity on those CPUs as much as possible.
I recently added the pe
Hi Peter,
Peter Zijlstra wrote:
[ You really ought to CC people :-) ]
I was not sure who though :)
Do we have a mailing list for scheduler development btw ?
Or it's just folks that you included in CC ?
Some of the latest scheduler patches brake things that I'm doing and I'd like
to make
them c
On Mon, 2008-01-28 at 11:34 -0500, Steven Rostedt wrote:
> On Mon, Jan 28, 2008 at 08:59:10AM -0600, Paul Jackson wrote:
> > Thanks for the CC, Peter.
>
> Thanks from me too.
>
> > Max wrote:
> > > We've had scheduler support for CPU isolation ever since O(1) scheduler
> > > went it.
> > > I'd
On Mon, Jan 28, 2008 at 08:59:10AM -0600, Paul Jackson wrote:
> Thanks for the CC, Peter.
Thanks from me too.
> Max wrote:
> > We've had scheduler support for CPU isolation ever since O(1) scheduler
> > went it.
> > I'd like to extend it further to avoid kernel activity on those CPUs as
> > mu
Thanks for the CC, Peter.
Ingo - see question at end of message.
Max wrote:
> We've had scheduler support for CPU isolation ever since O(1) scheduler went
> it.
> I'd like to extend it further to avoid kernel activity on those CPUs as much
> as possible.
I recently added the per-cpuset flag
[ You really ought to CC people :-) ]
On Sun, 2008-01-27 at 20:09 -0800, [EMAIL PROTECTED] wrote:
> Following patch series extends CPU isolation support. Yes, most people want
> to virtuallize
> CPUs these days and I want to isolate them :).
> The primary idea here is to be able to use some CPU
Following patch series extends CPU isolation support. Yes, most people want to
virtuallize
CPUs these days and I want to isolate them :).
The primary idea here is to be able to use some CPU cores as dedicated engines
for running
user-space code with minimal kernel overhead/intervention, think o
34 matches
Mail list logo
