On Wed, 17 Aug 2016, aruna.ramakris...@oracle.com wrote:
> I'll send out an updated slab counters patch with Joonsoo's suggested fix
> tomorrow (nr_slabs will be unsigned long for SLAB only, and there will be a
> separate definition for SLUB), and once that's in, I'll create a new patch
> that
On Wed, 17 Aug 2016, aruna.ramakris...@oracle.com wrote:
> I'll send out an updated slab counters patch with Joonsoo's suggested fix
> tomorrow (nr_slabs will be unsigned long for SLAB only, and there will be a
> separate definition for SLUB), and once that's in, I'll create a new patch
> that
On 08/16/2016 08:52 AM, Christoph Lameter wrote:
On Tue, 16 Aug 2016, Joonsoo Kim wrote:
In SLUB, nr_slabs is manipulated without holding a lock so atomic
operation should be used.
It could be moved under the node lock.
Christoph, Joonsoo,
I agree that nr_slabs could be common between
On 08/16/2016 08:52 AM, Christoph Lameter wrote:
On Tue, 16 Aug 2016, Joonsoo Kim wrote:
In SLUB, nr_slabs is manipulated without holding a lock so atomic
operation should be used.
It could be moved under the node lock.
Christoph, Joonsoo,
I agree that nr_slabs could be common between
On Tue, 16 Aug 2016, Joonsoo Kim wrote:
> In SLUB, nr_slabs is manipulated without holding a lock so atomic
> operation should be used.
It could be moved under the node lock.
On Tue, 16 Aug 2016, Joonsoo Kim wrote:
> In SLUB, nr_slabs is manipulated without holding a lock so atomic
> operation should be used.
It could be moved under the node lock.
On Fri, Aug 05, 2016 at 09:21:56AM -0500, Christoph Lameter wrote:
> On Fri, 5 Aug 2016, Joonsoo Kim wrote:
>
> > If above my comments are fixed, all counting would be done with
> > holding a lock. So, atomic definition isn't needed for the SLAB.
>
> Ditto for slub. struct kmem_cache_node is
On Fri, Aug 05, 2016 at 09:21:56AM -0500, Christoph Lameter wrote:
> On Fri, 5 Aug 2016, Joonsoo Kim wrote:
>
> > If above my comments are fixed, all counting would be done with
> > holding a lock. So, atomic definition isn't needed for the SLAB.
>
> Ditto for slub. struct kmem_cache_node is
On Fri, 5 Aug 2016, Joonsoo Kim wrote:
> If above my comments are fixed, all counting would be done with
> holding a lock. So, atomic definition isn't needed for the SLAB.
Ditto for slub. struct kmem_cache_node is alrady defined in mm/slab.h.
Thus it is a common definition already and can be
On Fri, 5 Aug 2016, Joonsoo Kim wrote:
> If above my comments are fixed, all counting would be done with
> holding a lock. So, atomic definition isn't needed for the SLAB.
Ditto for slub. struct kmem_cache_node is alrady defined in mm/slab.h.
Thus it is a common definition already and can be
On Thu, 4 Aug 2016, Aruna Ramakrishna wrote:
> On large systems, when some slab caches grow to millions of objects (and
> many gigabytes), running 'cat /proc/slabinfo' can take up to 1-2 seconds.
> During this time, interrupts are disabled while walking the slab lists
> (slabs_full,
On Thu, 4 Aug 2016, Aruna Ramakrishna wrote:
> On large systems, when some slab caches grow to millions of objects (and
> many gigabytes), running 'cat /proc/slabinfo' can take up to 1-2 seconds.
> During this time, interrupts are disabled while walking the slab lists
> (slabs_full,
2016-08-05 4:01 GMT+09:00 Aruna Ramakrishna :
> On large systems, when some slab caches grow to millions of objects (and
> many gigabytes), running 'cat /proc/slabinfo' can take up to 1-2 seconds.
> During this time, interrupts are disabled while walking the slab
2016-08-05 4:01 GMT+09:00 Aruna Ramakrishna :
> On large systems, when some slab caches grow to millions of objects (and
> many gigabytes), running 'cat /proc/slabinfo' can take up to 1-2 seconds.
> During this time, interrupts are disabled while walking the slab lists
> (slabs_full,
On 08/04/2016 02:06 PM, Andrew Morton wrote:
On Thu, 4 Aug 2016 12:01:13 -0700 Aruna Ramakrishna
wrote:
On large systems, when some slab caches grow to millions of objects (and
many gigabytes), running 'cat /proc/slabinfo' can take up to 1-2 seconds.
During
On 08/04/2016 02:06 PM, Andrew Morton wrote:
On Thu, 4 Aug 2016 12:01:13 -0700 Aruna Ramakrishna
wrote:
On large systems, when some slab caches grow to millions of objects (and
many gigabytes), running 'cat /proc/slabinfo' can take up to 1-2 seconds.
During this time, interrupts are
On Thu, 4 Aug 2016 12:01:13 -0700 Aruna Ramakrishna
wrote:
> On large systems, when some slab caches grow to millions of objects (and
> many gigabytes), running 'cat /proc/slabinfo' can take up to 1-2 seconds.
> During this time, interrupts are disabled while
On Thu, 4 Aug 2016 12:01:13 -0700 Aruna Ramakrishna
wrote:
> On large systems, when some slab caches grow to millions of objects (and
> many gigabytes), running 'cat /proc/slabinfo' can take up to 1-2 seconds.
> During this time, interrupts are disabled while walking the slab lists
>
On large systems, when some slab caches grow to millions of objects (and
many gigabytes), running 'cat /proc/slabinfo' can take up to 1-2 seconds.
During this time, interrupts are disabled while walking the slab lists
(slabs_full, slabs_partial, and slabs_free) for each node, and this
sometimes
On large systems, when some slab caches grow to millions of objects (and
many gigabytes), running 'cat /proc/slabinfo' can take up to 1-2 seconds.
During this time, interrupts are disabled while walking the slab lists
(slabs_full, slabs_partial, and slabs_free) for each node, and this
sometimes
20 matches
Mail list logo