From: Christoph Lameter <cl@linux.com>
To: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: akpm@linuxfoundation.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, penberg@kernel.org, iamjoonsoo@lge.com,
Jesper Dangaard Brouer <brouer@redhat.com>
Subject: Re: [PATCH 2/3] slub: Support for array operations
Date: Fri, 13 Feb 2015 09:49:24 -0600 (CST) [thread overview]
Message-ID: <alpine.DEB.2.11.1502130948120.9442@gentwo.org> (raw)
In-Reply-To: <20150213024515.GB6592@js1304-P5Q-DELUXE>
On Fri, 13 Feb 2015, Joonsoo Kim wrote:
> > + *p++ = freelist;
> > + freelist = get_freepointer(s, freelist);
> > + allocated++;
> > + }
>
> Fetching all objects with holding node lock could result in enomourous
> lock contention. How about getting free ojbect pointer without holding
> the node lock? We can temporarilly store all head of freelists in
> array p and can fetch each object pointer without holding node lock.
Could do that but lets first see if there is really an issue. The other
cpu sharing the same partial lists presumaly have cpu local objects to get
through first before they hit this lock.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2015-02-13 15:49 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-10 19:48 [PATCH 0/3] Slab allocator array operations V2 Christoph Lameter
2015-02-10 19:48 ` [PATCH 1/3] Slab infrastructure for array operations Christoph Lameter
2015-02-10 22:43 ` Jesper Dangaard Brouer
2015-02-10 23:58 ` David Rientjes
2015-02-11 18:47 ` Christoph Lameter
2015-02-11 20:18 ` David Rientjes
2015-02-11 22:04 ` Christoph Lameter
2015-02-12 0:35 ` David Rientjes
2015-02-13 2:35 ` Joonsoo Kim
2015-02-13 15:47 ` Christoph Lameter
2015-02-13 21:20 ` David Rientjes
2015-02-17 5:15 ` Joonsoo Kim
2015-02-17 16:03 ` Christoph Lameter
2015-02-17 21:32 ` Jesper Dangaard Brouer
2015-02-18 23:02 ` Christoph Lameter
2015-02-10 19:48 ` [PATCH 2/3] slub: Support " Christoph Lameter
2015-02-11 4:48 ` Jesper Dangaard Brouer
2015-02-11 19:07 ` Christoph Lameter
2015-02-11 21:43 ` Jesper Dangaard Brouer
2015-02-11 22:06 ` Christoph Lameter
2015-02-12 0:16 ` Jesper Dangaard Brouer
2015-02-12 2:46 ` Christoph Lameter
2015-02-13 2:45 ` Joonsoo Kim
2015-02-13 15:49 ` Christoph Lameter [this message]
2015-02-17 5:26 ` Joonsoo Kim
2015-02-10 19:48 ` [PATCH 3/3] Array alloc test code Christoph Lameter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.DEB.2.11.1502130948120.9442@gentwo.org \
--to=cl@linux.com \
--cc=akpm@linuxfoundation.org \
--cc=brouer@redhat.com \
--cc=iamjoonsoo.kim@lge.com \
--cc=iamjoonsoo@lge.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=penberg@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox