On Fri, Dec 5, 2014 at 12:20 AM, Christoph Lameter wrote:
> On Thu, 4 Dec 2014, Tejun Heo wrote:
>
>> Docker usage is pretty wide-spread now, making what used to be
>> siberia-cold paths hot enough to cause actual scalability issues.
>> Besides, we're now using percpu_ref for things like aio and
On Thu, 4 Dec 2014, Tejun Heo wrote:
> Docker usage is pretty wide-spread now, making what used to be
> siberia-cold paths hot enough to cause actual scalability issues.
> Besides, we're now using percpu_ref for things like aio and cgroup
> control structures which can be created and destroyed
On Thu, Dec 04, 2014 at 03:15:27PM -0600, Christoph Lameter wrote:
> On Thu, 4 Dec 2014, Al Viro wrote:
>
> > ... except that somebody has not known that and took refcounts on e.g.
> > vfsmounts into percpu. With massive amounts of hilarity once docker folks
> > started to test the workloads
On Thu, 4 Dec 2014, Al Viro wrote:
> ... except that somebody has not known that and took refcounts on e.g.
> vfsmounts into percpu. With massive amounts of hilarity once docker folks
> started to test the workloads that created/destroyed those in large amounts.
Well, vfsmounts being a
On Thu, Dec 04, 2014 at 02:28:10PM -0600, Christoph Lameter wrote:
> On Thu, 4 Dec 2014, Leonard Crestez wrote:
>
> > Yes, we are actually experiencing issues with this. We create lots of
> > virtual
> > net_devices and routes, which means lots of percpu counters/pointers. In
> > particular
> >
Hello, Christoph.
On Thu, Dec 04, 2014 at 02:28:10PM -0600, Christoph Lameter wrote:
> Well this is not a common use case and that is not what the per cpu
> allocator was designed for. There is bound to be signifcant fragmentation
> with the current design. The design was for rare allocations
On 12/04/2014 07:57 PM, Tejun Heo wrote:
> Hello,
>
> On Wed, Dec 03, 2014 at 12:33:59AM +0200, Leonard Crestez wrote:
>> It seems that free_percpu performance is very bad when working with small
>> objects. The easiest way to reproduce this is to allocate and then free a
>> large
>> number of
On Thu, Dec 04, 2014 at 10:10:18PM +0200, Leonard Crestez wrote:
> Yes, we are actually experiencing issues with this. We create lots of virtual
> net_devices and routes, which means lots of percpu counters/pointers. In
> particular
> we are getting worse performance than in older kernels because
On Thu, 4 Dec 2014, Leonard Crestez wrote:
> Yes, we are actually experiencing issues with this. We create lots of virtual
> net_devices and routes, which means lots of percpu counters/pointers. In
> particular
> we are getting worse performance than in older kernels because the net_device
>
Hello,
On Wed, Dec 03, 2014 at 12:33:59AM +0200, Leonard Crestez wrote:
> It seems that free_percpu performance is very bad when working with small
> objects. The easiest way to reproduce this is to allocate and then free a
> large
> number of percpu int counters in order. Small objects
Hello,
On Wed, Dec 03, 2014 at 12:33:59AM +0200, Leonard Crestez wrote:
It seems that free_percpu performance is very bad when working with small
objects. The easiest way to reproduce this is to allocate and then free a
large
number of percpu int counters in order. Small objects (reference
On Thu, 4 Dec 2014, Leonard Crestez wrote:
Yes, we are actually experiencing issues with this. We create lots of virtual
net_devices and routes, which means lots of percpu counters/pointers. In
particular
we are getting worse performance than in older kernels because the net_device
refcnt
On Thu, Dec 04, 2014 at 10:10:18PM +0200, Leonard Crestez wrote:
Yes, we are actually experiencing issues with this. We create lots of virtual
net_devices and routes, which means lots of percpu counters/pointers. In
particular
we are getting worse performance than in older kernels because the
On 12/04/2014 07:57 PM, Tejun Heo wrote:
Hello,
On Wed, Dec 03, 2014 at 12:33:59AM +0200, Leonard Crestez wrote:
It seems that free_percpu performance is very bad when working with small
objects. The easiest way to reproduce this is to allocate and then free a
large
number of percpu int
Hello, Christoph.
On Thu, Dec 04, 2014 at 02:28:10PM -0600, Christoph Lameter wrote:
Well this is not a common use case and that is not what the per cpu
allocator was designed for. There is bound to be signifcant fragmentation
with the current design. The design was for rare allocations when
On Thu, Dec 04, 2014 at 02:28:10PM -0600, Christoph Lameter wrote:
On Thu, 4 Dec 2014, Leonard Crestez wrote:
Yes, we are actually experiencing issues with this. We create lots of
virtual
net_devices and routes, which means lots of percpu counters/pointers. In
particular
we are
On Thu, 4 Dec 2014, Al Viro wrote:
... except that somebody has not known that and took refcounts on e.g.
vfsmounts into percpu. With massive amounts of hilarity once docker folks
started to test the workloads that created/destroyed those in large amounts.
Well, vfsmounts being a performance
On Thu, Dec 04, 2014 at 03:15:27PM -0600, Christoph Lameter wrote:
On Thu, 4 Dec 2014, Al Viro wrote:
... except that somebody has not known that and took refcounts on e.g.
vfsmounts into percpu. With massive amounts of hilarity once docker folks
started to test the workloads that
On Thu, 4 Dec 2014, Tejun Heo wrote:
Docker usage is pretty wide-spread now, making what used to be
siberia-cold paths hot enough to cause actual scalability issues.
Besides, we're now using percpu_ref for things like aio and cgroup
control structures which can be created and destroyed quite
On Fri, Dec 5, 2014 at 12:20 AM, Christoph Lameter c...@linux.com wrote:
On Thu, 4 Dec 2014, Tejun Heo wrote:
Docker usage is pretty wide-spread now, making what used to be
siberia-cold paths hot enough to cause actual scalability issues.
Besides, we're now using percpu_ref for things like
Hello,
It seems that free_percpu performance is very bad when working with small
objects. The easiest way to reproduce this is to allocate and then free a large
number of percpu int counters in order. Small objects (reference counters and
pointers) are common users of alloc_percpu and I think
Hello,
It seems that free_percpu performance is very bad when working with small
objects. The easiest way to reproduce this is to allocate and then free a large
number of percpu int counters in order. Small objects (reference counters and
pointers) are common users of alloc_percpu and I think
22 matches
Mail list logo
