> On Mar 23, 2021, at 4:13 PM, Jason Gunthorpe wrote:
>
> On Tue, Mar 23, 2021 at 12:41:51PM -0700, Aruna Ramakrishna wrote:
>> There is a far greater possibility of an order-8 allocation failing,
>> esp. with the addition of __GFP_NORETRY , and the code would h
-by: Aruna Ramakrishna
Thanks,
Aruna
On 08/29/2016 05:44 PM, 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, slabs_partial
On 08/29/2016 05:44 PM, 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, slabs_partial
than slabs_full. We tested this after
growing the dentry cache to 70GB, and the performance improved from 2s to
5ms.
Signed-off-by: Aruna Ramakrishna <aruna.ramakris...@oracle.com>
Cc: Mike Kravetz <mike.krav...@oracle.com>
Cc: Christoph Lameter <c...@linux.com>
Cc: Pekka Enberg &
than slabs_full. We tested this after
growing the dentry cache to 70GB, and the performance improved from 2s to
5ms.
Signed-off-by: Aruna Ramakrishna
Cc: Mike Kravetz
Cc: Christoph Lameter
Cc: Pekka Enberg
Cc: David Rientjes
Cc: Joonsoo Kim
Cc: Andrew Morton
---
Note: this has been tested only
On 08/18/2016 04:52 AM, Michal Hocko wrote:
I am not opposing the patch (to be honest it is quite neat) but this
is buggering me for quite some time. Sorry for hijacking this email
thread but I couldn't resist. Why are we trying to optimize SLAB and
slowly converge it to SLUB feature-wise. I
On 08/18/2016 04:52 AM, Michal Hocko wrote:
I am not opposing the patch (to be honest it is quite neat) but this
is buggering me for quite some time. Sorry for hijacking this email
thread but I couldn't resist. Why are we trying to optimize SLAB and
slowly converge it to SLUB feature-wise. I
than slabs_full. We tested this after
growing the dentry cache to 70GB, and the performance improved from 2s to
5ms.
Signed-off-by: Aruna Ramakrishna <aruna.ramakris...@oracle.com>
Cc: Mike Kravetz <mike.krav...@oracle.com>
Cc: Christoph Lameter <c...@linux.com>
Cc: Pekka Enberg &
than slabs_full. We tested this after
growing the dentry cache to 70GB, and the performance improved from 2s to
5ms.
Signed-off-by: Aruna Ramakrishna
Cc: Mike Kravetz
Cc: Christoph Lameter
Cc: Pekka Enberg
Cc: David Rientjes
Cc: Joonsoo Kim
Cc: Andrew Morton
---
Note: this has been tested only
On 08/17/2016 12:03 PM, Eric Dumazet wrote:
On Wed, 2016-08-17 at 11:20 -0700, Aruna Ramakrishna wrote:
]
- list_for_each_entry(page, >slabs_full, lru) {
- if (page->active != cachep->num && !error)
- er
On 08/17/2016 12:03 PM, Eric Dumazet wrote:
On Wed, 2016-08-17 at 11:20 -0700, Aruna Ramakrishna wrote:
]
- list_for_each_entry(page, >slabs_full, lru) {
- if (page->active != cachep->num && !error)
- er
than slabs_full. We tested this after
growing the dentry cache to 70GB, and the performance improved from 2s to
5ms.
Signed-off-by: Aruna Ramakrishna <aruna.ramakris...@oracle.com>
Cc: Mike Kravetz <mike.krav...@oracle.com>
Cc: Christoph Lameter <c...@linux.com>
Cc: Pekka Enberg &
than slabs_full. We tested this after
growing the dentry cache to 70GB, and the performance improved from 2s to
5ms.
Signed-off-by: Aruna Ramakrishna
Cc: Mike Kravetz
Cc: Christoph Lameter
Cc: Pekka Enberg
Cc: David Rientjes
Cc: Joonsoo Kim
Cc: Andrew Morton
---
Note: this has been tested only
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 08/04/2016 02:06 PM, Andrew Morton wrote:
On Thu, 4 Aug 2016 12:01:13 -0700 Aruna Ramakrishna
<aruna.ramakris...@oracle.com> 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.
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
than slabs_full. We tested this after
growing the dentry cache to 70GB, and the performance improved from 2s to
5ms.
Signed-off-by: Aruna Ramakrishna <aruna.ramakris...@oracle.com>
Cc: Mike Kravetz <mike.krav...@oracle.com>
Cc: Christoph Lameter <c...@linux.com>
Cc: Pekka Enberg &
than slabs_full. We tested this after
growing the dentry cache to 70GB, and the performance improved from 2s to
5ms.
Signed-off-by: Aruna Ramakrishna
Cc: Mike Kravetz
Cc: Christoph Lameter
Cc: Pekka Enberg
Cc: David Rientjes
Cc: Joonsoo Kim
Cc: Andrew Morton
---
Note: this has been tested only
On 08/02/2016 07:59 AM, Christoph Lameter wrote:
Hmm What SLUB does is:
1. Keep a count of the total number of allocated slab pages per node.
This counter only needs to be updated when a slab page is
allocated from the page allocator or when it is freed to the
page
On 08/02/2016 07:59 AM, Christoph Lameter wrote:
Hmm What SLUB does is:
1. Keep a count of the total number of allocated slab pages per node.
This counter only needs to be updated when a slab page is
allocated from the page allocator or when it is freed to the
page
Hi Joonsoo,
On 08/01/2016 05:55 PM, Joonsoo Kim wrote:
Your patch updates these counters not only when a slabs are created and
destroyed but also when object is allocated/freed from the slab. This
would hurt runtime performance.
The counters are not updated for each object allocation/free -
Hi Joonsoo,
On 08/01/2016 05:55 PM, Joonsoo Kim wrote:
Your patch updates these counters not only when a slabs are created and
destroyed but also when object is allocated/freed from the slab. This
would hurt runtime performance.
The counters are not updated for each object allocation/free -
for gathering slabinfo stats, resulting in a dramatic
performance improvement. We tested this after growing the dentry cache to
70GB, and the performance improved from 2s to 2ms.
Signed-off-by: Aruna Ramakrishna <aruna.ramakris...@oracle.com>
Cc: Mike Kravetz <mike.krav...@oracle.com>
Cc: Chris
for gathering slabinfo stats, resulting in a dramatic
performance improvement. We tested this after growing the dentry cache to
70GB, and the performance improved from 2s to 2ms.
Signed-off-by: Aruna Ramakrishna
Cc: Mike Kravetz
Cc: Christoph Lameter
Cc: Pekka Enberg
Cc: David Rientjes
Cc: Joonsoo Kim
26 matches
Mail list logo
