Hello, Michal.
On Mon, Jun 17, 2013 at 03:27:44PM +0200, Michal Hocko wrote:
> Thanks for your results! Yes the boost can be really high. I will try to
> measure some memcg workloads as soon as I have some spare cycles. I do
> not expect a big win but I also do not think this would regress.
With
On Fri 14-06-13 22:35:22, Tejun Heo wrote:
> On Fri, Jun 14, 2013 at 03:31:25PM -0700, Tejun Heo wrote:
> > I'll play with it a bit more on an actual machine and post more
> > results. Test program attached.
>
> So, here are the results from the same test on a dual-socket 2-way
> NUMA opteron 8
On Fri 14-06-13 22:35:22, Tejun Heo wrote:
On Fri, Jun 14, 2013 at 03:31:25PM -0700, Tejun Heo wrote:
I'll play with it a bit more on an actual machine and post more
results. Test program attached.
So, here are the results from the same test on a dual-socket 2-way
NUMA opteron 8 core
Hello, Michal.
On Mon, Jun 17, 2013 at 03:27:44PM +0200, Michal Hocko wrote:
Thanks for your results! Yes the boost can be really high. I will try to
measure some memcg workloads as soon as I have some spare cycles. I do
not expect a big win but I also do not think this would regress.
With
On Fri, Jun 14, 2013 at 10:35:22PM -0700, Tejun Heo wrote:
> On Fri, Jun 14, 2013 at 03:31:25PM -0700, Tejun Heo wrote:
> > I'll play with it a bit more on an actual machine and post more
> > results. Test program attached.
>
> So, here are the results from the same test on a dual-socket 2-way
>
On Fri, Jun 14, 2013 at 10:35:22PM -0700, Tejun Heo wrote:
On Fri, Jun 14, 2013 at 03:31:25PM -0700, Tejun Heo wrote:
I'll play with it a bit more on an actual machine and post more
results. Test program attached.
So, here are the results from the same test on a dual-socket 2-way
NUMA
On Fri, Jun 14, 2013 at 10:35:22PM -0700, Tejun Heo wrote:
> On Fri, Jun 14, 2013 at 03:31:25PM -0700, Tejun Heo wrote:
> > I'll play with it a bit more on an actual machine and post more
> > results. Test program attached.
>
> So, here are the results from the same test on a dual-socket 2-way
>
On Fri, Jun 14, 2013 at 03:31:25PM -0700, Tejun Heo wrote:
> I'll play with it a bit more on an actual machine and post more
> results. Test program attached.
So, here are the results from the same test on a dual-socket 2-way
NUMA opteron 8 core machine.
Running on one CPU.
copy size
Hello, Michal.
On Fri, Jun 14, 2013 at 03:20:26PM +0200, Michal Hocko wrote:
> I have no objections to change css reference counting scheme if the
> guarantees we used to have are still valid. I am just missing some
> comparisons. Do you have any numbers that would show benefits clearly?
On Fri 14-06-13 18:15:12, Glauber Costa wrote:
> On Fri, Jun 14, 2013 at 02:55:39PM +0200, Michal Hocko wrote:
> > On Wed 12-06-13 21:04:58, Tejun Heo wrote:
> > [...]
> > > +/**
> > > + * cgroup_destroy_locked - the first stage of cgroup destruction
> > > + * @cgrp: cgroup to be destroyed
> > > +
On Fri, Jun 14, 2013 at 02:55:39PM +0200, Michal Hocko wrote:
> On Wed 12-06-13 21:04:58, Tejun Heo wrote:
> [...]
> > +/**
> > + * cgroup_destroy_locked - the first stage of cgroup destruction
> > + * @cgrp: cgroup to be destroyed
> > + *
> > + * css's make use of percpu refcnts whose killing
On Wed 12-06-13 21:04:58, Tejun Heo wrote:
> A css (cgroup_subsys_state) is how each cgroup is represented to a
> controller. As such, it can be used in hot paths across the various
> subsystems different controllers are associated with.
>
> One of the common operations is reference counting,
On Wed 12-06-13 21:04:58, Tejun Heo wrote:
[...]
> +/**
> + * cgroup_destroy_locked - the first stage of cgroup destruction
> + * @cgrp: cgroup to be destroyed
> + *
> + * css's make use of percpu refcnts whose killing latency shouldn't be
> + * exposed to userland and are RCU protected. Also,
On Wed 12-06-13 21:04:58, Tejun Heo wrote:
[...]
+/**
+ * cgroup_destroy_locked - the first stage of cgroup destruction
+ * @cgrp: cgroup to be destroyed
+ *
+ * css's make use of percpu refcnts whose killing latency shouldn't be
+ * exposed to userland and are RCU protected. Also, cgroup
On Wed 12-06-13 21:04:58, Tejun Heo wrote:
A css (cgroup_subsys_state) is how each cgroup is represented to a
controller. As such, it can be used in hot paths across the various
subsystems different controllers are associated with.
One of the common operations is reference counting, which
On Fri, Jun 14, 2013 at 02:55:39PM +0200, Michal Hocko wrote:
On Wed 12-06-13 21:04:58, Tejun Heo wrote:
[...]
+/**
+ * cgroup_destroy_locked - the first stage of cgroup destruction
+ * @cgrp: cgroup to be destroyed
+ *
+ * css's make use of percpu refcnts whose killing latency
On Fri 14-06-13 18:15:12, Glauber Costa wrote:
On Fri, Jun 14, 2013 at 02:55:39PM +0200, Michal Hocko wrote:
On Wed 12-06-13 21:04:58, Tejun Heo wrote:
[...]
+/**
+ * cgroup_destroy_locked - the first stage of cgroup destruction
+ * @cgrp: cgroup to be destroyed
+ *
+ * css's
Hello, Michal.
On Fri, Jun 14, 2013 at 03:20:26PM +0200, Michal Hocko wrote:
I have no objections to change css reference counting scheme if the
guarantees we used to have are still valid. I am just missing some
comparisons. Do you have any numbers that would show benefits clearly?
Mikulas'
On Fri, Jun 14, 2013 at 03:31:25PM -0700, Tejun Heo wrote:
I'll play with it a bit more on an actual machine and post more
results. Test program attached.
So, here are the results from the same test on a dual-socket 2-way
NUMA opteron 8 core machine.
Running on one CPU.
copy size
On Fri, Jun 14, 2013 at 10:35:22PM -0700, Tejun Heo wrote:
On Fri, Jun 14, 2013 at 03:31:25PM -0700, Tejun Heo wrote:
I'll play with it a bit more on an actual machine and post more
results. Test program attached.
So, here are the results from the same test on a dual-socket 2-way
NUMA
On Wed, Jun 12, 2013 at 09:04:58PM -0700, Tejun Heo wrote:
> A css (cgroup_subsys_state) is how each cgroup is represented to a
> controller. As such, it can be used in hot paths across the various
> subsystems different controllers are associated with.
>
> One of the common operations is
On Wed, Jun 12, 2013 at 09:04:58PM -0700, Tejun Heo wrote:
A css (cgroup_subsys_state) is how each cgroup is represented to a
controller. As such, it can be used in hot paths across the various
subsystems different controllers are associated with.
One of the common operations is reference
A css (cgroup_subsys_state) is how each cgroup is represented to a
controller. As such, it can be used in hot paths across the various
subsystems different controllers are associated with.
One of the common operations is reference counting, which up until now
has been implemented using a global
A css (cgroup_subsys_state) is how each cgroup is represented to a
controller. As such, it can be used in hot paths across the various
subsystems different controllers are associated with.
One of the common operations is reference counting, which up until now
has been implemented using a global
A css (cgroup_subsys_state) is how each cgroup is represented to a
controller. As such, it can be used in hot paths across the various
subsystems different controllers are associated with.
One of the common operations is reference counting, which up until now
has been implemented using a global
A css (cgroup_subsys_state) is how each cgroup is represented to a
controller. As such, it can be used in hot paths across the various
subsystems different controllers are associated with.
One of the common operations is reference counting, which up until now
has been implemented using a global
26 matches
Mail list logo
