On Mon, Sep 29, 2014 at 10:03:15AM -0700, Jeremiah Mahler wrote:
> Joonsoo,
>
> On Mon, Sep 29, 2014 at 04:44:18PM +0900, Joonsoo Kim wrote:
> > On Sat, Sep 27, 2014 at 11:24:49PM -0700, Jeremiah Mahler wrote:
> > > On Thu, Aug 21, 2014 at 05:11:13PM +0900, Joonsoo Kim wrote:
> > > > Because of
On Mon, Sep 29, 2014 at 10:03:15AM -0700, Jeremiah Mahler wrote:
Joonsoo,
On Mon, Sep 29, 2014 at 04:44:18PM +0900, Joonsoo Kim wrote:
On Sat, Sep 27, 2014 at 11:24:49PM -0700, Jeremiah Mahler wrote:
On Thu, Aug 21, 2014 at 05:11:13PM +0900, Joonsoo Kim wrote:
Because of chicken and
Joonsoo,
On Mon, Sep 29, 2014 at 04:44:18PM +0900, Joonsoo Kim wrote:
> On Sat, Sep 27, 2014 at 11:24:49PM -0700, Jeremiah Mahler wrote:
> > On Thu, Aug 21, 2014 at 05:11:13PM +0900, Joonsoo Kim wrote:
> > > Because of chicken and egg problem, initializaion of SLAB is really
> > > complicated. We
On Sat, Sep 27, 2014 at 11:24:49PM -0700, Jeremiah Mahler wrote:
> On Thu, Aug 21, 2014 at 05:11:13PM +0900, Joonsoo Kim wrote:
> > Because of chicken and egg problem, initializaion of SLAB is really
> > complicated. We need to allocate cpu cache through SLAB to make
> > the kmem_cache works, but,
On Sat, Sep 27, 2014 at 11:24:49PM -0700, Jeremiah Mahler wrote:
On Thu, Aug 21, 2014 at 05:11:13PM +0900, Joonsoo Kim wrote:
Because of chicken and egg problem, initializaion of SLAB is really
complicated. We need to allocate cpu cache through SLAB to make
the kmem_cache works, but, before
Joonsoo,
On Mon, Sep 29, 2014 at 04:44:18PM +0900, Joonsoo Kim wrote:
On Sat, Sep 27, 2014 at 11:24:49PM -0700, Jeremiah Mahler wrote:
On Thu, Aug 21, 2014 at 05:11:13PM +0900, Joonsoo Kim wrote:
Because of chicken and egg problem, initializaion of SLAB is really
complicated. We need to
On Sun, Sep 28, 2014 at 11:38:51AM -0500, Christoph Lameter wrote:
> On Sat, 27 Sep 2014, Jeremiah Mahler wrote:
>
> > I just encountered a problem on a Lenovo Carbon X1 where it will
> > suspend but won't resume. A bisect indicated that this patch
> > is causing the problem.
>
> Could you
On Sat, 27 Sep 2014, Jeremiah Mahler wrote:
> I just encountered a problem on a Lenovo Carbon X1 where it will
> suspend but won't resume. A bisect indicated that this patch
> is causing the problem.
Could you please not quote the whole patch. Took me a while to find what
you were saying.
>
On Thu, Aug 21, 2014 at 05:11:13PM +0900, Joonsoo Kim wrote:
> Because of chicken and egg problem, initializaion of SLAB is really
> complicated. We need to allocate cpu cache through SLAB to make
> the kmem_cache works, but, before initialization of kmem_cache,
> allocation through SLAB is
On Thu, Aug 21, 2014 at 05:11:13PM +0900, Joonsoo Kim wrote:
Because of chicken and egg problem, initializaion of SLAB is really
complicated. We need to allocate cpu cache through SLAB to make
the kmem_cache works, but, before initialization of kmem_cache,
allocation through SLAB is
On Sat, 27 Sep 2014, Jeremiah Mahler wrote:
I just encountered a problem on a Lenovo Carbon X1 where it will
suspend but won't resume. A bisect indicated that this patch
is causing the problem.
Could you please not quote the whole patch. Took me a while to find what
you were saying.
On Sun, Sep 28, 2014 at 11:38:51AM -0500, Christoph Lameter wrote:
On Sat, 27 Sep 2014, Jeremiah Mahler wrote:
I just encountered a problem on a Lenovo Carbon X1 where it will
suspend but won't resume. A bisect indicated that this patch
is causing the problem.
Could you please not
On Wed, Aug 27, 2014 at 06:37:33PM -0500, Christoph Lameter wrote:
> One minor nit. Otherwise
>
> Acked-by: Christoph Lameter
>
> On Thu, 21 Aug 2014, Joonsoo Kim wrote:
>
> > @@ -2041,56 +1982,63 @@ static size_t calculate_slab_order(struct
> > kmem_cache *cachep,
> > return left_over;
>
On Wed, Aug 27, 2014 at 06:37:33PM -0500, Christoph Lameter wrote:
One minor nit. Otherwise
Acked-by: Christoph Lameter c...@linux.com
On Thu, 21 Aug 2014, Joonsoo Kim wrote:
@@ -2041,56 +1982,63 @@ static size_t calculate_slab_order(struct
kmem_cache *cachep,
return left_over;
One minor nit. Otherwise
Acked-by: Christoph Lameter
On Thu, 21 Aug 2014, Joonsoo Kim wrote:
> @@ -2041,56 +1982,63 @@ static size_t calculate_slab_order(struct kmem_cache
> *cachep,
> return left_over;
> }
>
> +static int alloc_kmem_cache_cpus(struct kmem_cache *cachep, int entries,
>
One minor nit. Otherwise
Acked-by: Christoph Lameter c...@linux.com
On Thu, 21 Aug 2014, Joonsoo Kim wrote:
@@ -2041,56 +1982,63 @@ static size_t calculate_slab_order(struct kmem_cache
*cachep,
return left_over;
}
+static int alloc_kmem_cache_cpus(struct kmem_cache *cachep, int
On Tue, 26 Aug 2014, Joonsoo Kim wrote:
> > What case? SLUB uses a linked list and therefore does not have these
> > storage requirements.
>
> I misunderstand that you mentioned just memory usage. My *any case*
> means memory usage of previous SLAB and SLAB with this percpu alloc
> change. Sorry
On Tue, 26 Aug 2014, Joonsoo Kim wrote:
What case? SLUB uses a linked list and therefore does not have these
storage requirements.
I misunderstand that you mentioned just memory usage. My *any case*
means memory usage of previous SLAB and SLAB with this percpu alloc
change. Sorry for
On Mon, Aug 25, 2014 at 08:13:58AM -0500, Christoph Lameter wrote:
> On Mon, 25 Aug 2014, Joonsoo Kim wrote:
>
> > On Thu, Aug 21, 2014 at 09:21:30AM -0500, Christoph Lameter wrote:
> > > On Thu, 21 Aug 2014, Joonsoo Kim wrote:
> > >
> > > > So, this patch try to use percpu allocator in SLAB.
On Mon, 25 Aug 2014, Joonsoo Kim wrote:
> On Thu, Aug 21, 2014 at 09:21:30AM -0500, Christoph Lameter wrote:
> > On Thu, 21 Aug 2014, Joonsoo Kim wrote:
> >
> > > So, this patch try to use percpu allocator in SLAB. This simplify
> > > initialization step in SLAB so that we could maintain SLAB
On Thu, Aug 21, 2014 at 09:21:30AM -0500, Christoph Lameter wrote:
> On Thu, 21 Aug 2014, Joonsoo Kim wrote:
>
> > So, this patch try to use percpu allocator in SLAB. This simplify
> > initialization step in SLAB so that we could maintain SLAB code more
> > easily.
>
> I thought about this a
On Thu, Aug 21, 2014 at 09:21:30AM -0500, Christoph Lameter wrote:
On Thu, 21 Aug 2014, Joonsoo Kim wrote:
So, this patch try to use percpu allocator in SLAB. This simplify
initialization step in SLAB so that we could maintain SLAB code more
easily.
I thought about this a couple of
On Mon, 25 Aug 2014, Joonsoo Kim wrote:
On Thu, Aug 21, 2014 at 09:21:30AM -0500, Christoph Lameter wrote:
On Thu, 21 Aug 2014, Joonsoo Kim wrote:
So, this patch try to use percpu allocator in SLAB. This simplify
initialization step in SLAB so that we could maintain SLAB code more
On Mon, Aug 25, 2014 at 08:13:58AM -0500, Christoph Lameter wrote:
On Mon, 25 Aug 2014, Joonsoo Kim wrote:
On Thu, Aug 21, 2014 at 09:21:30AM -0500, Christoph Lameter wrote:
On Thu, 21 Aug 2014, Joonsoo Kim wrote:
So, this patch try to use percpu allocator in SLAB. This simplify
On Thu, 21 Aug 2014, Joonsoo Kim wrote:
> So, this patch try to use percpu allocator in SLAB. This simplify
> initialization step in SLAB so that we could maintain SLAB code more
> easily.
I thought about this a couple of times but the amount of memory used for
the per cpu arrays can be huge. In
Because of chicken and egg problem, initializaion of SLAB is really
complicated. We need to allocate cpu cache through SLAB to make
the kmem_cache works, but, before initialization of kmem_cache,
allocation through SLAB is impossible.
On the other hand, SLUB does initialization with more simple
Because of chicken and egg problem, initializaion of SLAB is really
complicated. We need to allocate cpu cache through SLAB to make
the kmem_cache works, but, before initialization of kmem_cache,
allocation through SLAB is impossible.
On the other hand, SLUB does initialization with more simple
On Thu, 21 Aug 2014, Joonsoo Kim wrote:
So, this patch try to use percpu allocator in SLAB. This simplify
initialization step in SLAB so that we could maintain SLAB code more
easily.
I thought about this a couple of times but the amount of memory used for
the per cpu arrays can be huge. In
28 matches
Mail list logo
