Paul Jackson wrote:
So. I see cpusets as a higher level API/mechanism and cpu_isolated_map as lower
level mechanism that actually makes kernel aware of what's isolated what's not.
Kind of like sched domain/cpuset relationship. ie cpusets affect sched domains
but scheduler does not use cpusets
> So. I see cpusets as a higher level API/mechanism and cpu_isolated_map as
> lower
> level mechanism that actually makes kernel aware of what's isolated what's
> not.
> Kind of like sched domain/cpuset relationship. ie cpusets affect sched domains
> but scheduler does not use cpusets directly.
So. I see cpusets as a higher level API/mechanism and cpu_isolated_map as
lower
level mechanism that actually makes kernel aware of what's isolated what's
not.
Kind of like sched domain/cpuset relationship. ie cpusets affect sched domains
but scheduler does not use cpusets directly.
One
Paul Jackson wrote:
So. I see cpusets as a higher level API/mechanism and cpu_isolated_map as lower
level mechanism that actually makes kernel aware of what's isolated what's not.
Kind of like sched domain/cpuset relationship. ie cpusets affect sched domains
but scheduler does not use cpusets
Hi Pual
> Looking at some IA64 sn2 config builds I have laying about, I see the
> following text sizes for a couple of versions, showing the growth of
> the cpuset/cgroup apparatus over time:
>
> 25933 2.6.18-rc3-mm1/kernel/cpuset.o (Aug 2006)
> vs.
> 37823
Hi Pual
Looking at some IA64 sn2 config builds I have laying about, I see the
following text sizes for a couple of versions, showing the growth of
the cpuset/cgroup apparatus over time:
25933 2.6.18-rc3-mm1/kernel/cpuset.o (Aug 2006)
vs.
37823
Hi Paul,
> A couple of proposals have been made recently by people working Linux
> on smaller systems, for improving realtime isolation and memory
> pressure handling:
>
> (1) cpu isolation for hard(er) realtime
> http://lkml.org/lkml/2008/2/21/517
> Max Krasnyanskiy <[EMAIL
Paul M wrote:
> I'm don't think that either of these would be enough to justify big
> changes to cpusets or cgroups, although eliminating bloat is always a
> good thing.
My "tiny cpuset" idea doesn't so much eliminate bloat, as provide a
thin alternative, along side of the existing fat
On Sat, Feb 23, 2008 at 4:09 AM, Paul Jackson <[EMAIL PROTECTED]> wrote:
> A couple of proposals have been made recently by people working Linux
> on smaller systems, for improving realtime isolation and memory
> pressure handling:
>
> (1) cpu isolation for hard(er) realtime
>
A couple of proposals have been made recently by people working Linux
on smaller systems, for improving realtime isolation and memory
pressure handling:
(1) cpu isolation for hard(er) realtime
http://lkml.org/lkml/2008/2/21/517
Max Krasnyanskiy <[EMAIL PROTECTED]>
[PATCH
A couple of proposals have been made recently by people working Linux
on smaller systems, for improving realtime isolation and memory
pressure handling:
(1) cpu isolation for hard(er) realtime
http://lkml.org/lkml/2008/2/21/517
Max Krasnyanskiy [EMAIL PROTECTED]
[PATCH
On Sat, Feb 23, 2008 at 4:09 AM, Paul Jackson [EMAIL PROTECTED] wrote:
A couple of proposals have been made recently by people working Linux
on smaller systems, for improving realtime isolation and memory
pressure handling:
(1) cpu isolation for hard(er) realtime
Paul M wrote:
I'm don't think that either of these would be enough to justify big
changes to cpusets or cgroups, although eliminating bloat is always a
good thing.
My tiny cpuset idea doesn't so much eliminate bloat, as provide a
thin alternative, along side of the existing fat alternative.
Hi Paul,
A couple of proposals have been made recently by people working Linux
on smaller systems, for improving realtime isolation and memory
pressure handling:
(1) cpu isolation for hard(er) realtime
http://lkml.org/lkml/2008/2/21/517
Max Krasnyanskiy [EMAIL PROTECTED]
14 matches
Mail list logo
